NPTL patch for linux 2.4.28

NPTL patch for linux 2.4.28

[Syed Ahemed]

Hello all.
I have a tricky problem on  hand and a straight forward question.

Tricky problem:
---------------------
While debugging a simple multithreaded application using gdb linux
2.4.28 , i noticed the thread that has crashed after sigsegv has
complete information on the gdb (both  address and function at the
time of crash ) .But the other threads that are in wait state (
executing glibc functions at the time of crash ) just has the address
but not the function name as shown below.


sh-2.05b# ./gdb a.out /mnt/cf/engg_files/core_files/
a.out.1173437318.core.5312   a.out.1173453940.core.9829
a.out.1173438125.core.16016  lost+found
a.out.1173438881.core.18721
<f/engg_files/core_files/a.out.1173453940.core.9829
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library
 "/lib/libthread_db.so.1".

warning: exec file is newer than core file.
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /opt/lib/ld-linux.so.2...done.
Loaded symbols for /opt//lib/ld-linux.so.2
#0  0x080485df in a (p=0x0) at threadcore.c:34
34      threadcore.c: No such file or directory.
        in threadcore.c
(gdb) info threads
  3 process 10993  0x08053840 in ?? ()
  2 process 1267  0xbf5ff9d0 in ?? ()
* 1 process 9829  0x080485df in a (p=0x0) at threadcore.c:34
(gdb) thread 3
[Switching to thread 3 (process 10993)]#0  0x08053840 in ?? ()
(gdb) bt
#0  0x08053840 in ?? ()
Cannot access memory at address 0x2b
(gdb)
#0  0x08053840 in ?? ()
Cannot access memory at address 0x2b
(gdb) thread 1
[Switching to thread 1 (process 9829)]#0  0x080485df in a (p=0x0)
    at threadcore.c:34
34      in threadcore.c
(gdb) bt
#0  0x080485df in a (p=0x0) at threadcore.c:34
#1  0x080485bc in main () at threadcore.c:21
(gdb) thread 2
[Switching to thread 2 (process 1267)]#0  0xbf5ff9d0 in ?? ()
(gdb) bt
#0  0xbf5ff9d0 in ?? ()
Cannot access memory at address 0x2b
(gdb) q
sh-2.05b#


The problem is with the same glibc and gdb , Redhat 9 linux 2.4.20-8
does  give me complete information of all the threads in the "info
threads" command.
Having read similar problems on various mailing lists , i believe the
only difference is redhat 9 has patched its kernel with NTPL or
debugging support for linux in the kernel.

Wanted to confirm if it this correct .

My question
------------------

Someone would say move to 2.6 kernel and a different glibc,But with
custom applications at stake .I can't take that risk as yet .So i
would want an NTPL patch for 2.4.28 kernel
Where do i get it ? Please do respond .




Regards
-- 
Syed

I'm afraid that I've seen too many people fix bugs by looking at
debugger output, and that almost inevitably leads to fixing the
symptoms rather than the underlying problems.
	
--Linus

Re: NPTL patch for linux 2.4.28

[Willy Tarreau]

On Wed, Mar 14, 2007 at 05:49:22AM +0530, Syed Ahemed wrote:
> Hello all.
> I have a tricky problem on  hand and a straight forward question.
> 
> Tricky problem:
> ---------------------
> While debugging a simple multithreaded application using gdb linux
> 2.4.28 , i noticed the thread that has crashed after sigsegv has
> complete information on the gdb (both  address and function at the
> time of crash ) .But the other threads that are in wait state (
> executing glibc functions at the time of crash ) just has the address
> but not the function name as shown below.
> 
> 
> sh-2.05b# ./gdb a.out /mnt/cf/engg_files/core_files/
> a.out.1173437318.core.5312   a.out.1173453940.core.9829
> a.out.1173438125.core.16016  lost+found
> a.out.1173438881.core.18721
> <f/engg_files/core_files/a.out.1173453940.core.9829
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain 
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db 
> library
> "/lib/libthread_db.so.1".
> 
> warning: exec file is newer than core file.
> Core was generated by `./a.out'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libpthread.so.0...done.
> Loaded symbols for /lib/libpthread.so.0
> Reading symbols from /lib/libc.so.6...done.
> Loaded symbols for /lib/libc.so.6
> Reading symbols from /opt/lib/ld-linux.so.2...done.
> Loaded symbols for /opt//lib/ld-linux.so.2
> #0  0x080485df in a (p=0x0) at threadcore.c:34
> 34      threadcore.c: No such file or directory.
>        in threadcore.c
> (gdb) info threads
>  3 process 10993  0x08053840 in ?? ()
>  2 process 1267  0xbf5ff9d0 in ?? ()
> * 1 process 9829  0x080485df in a (p=0x0) at threadcore.c:34
> (gdb) thread 3
> [Switching to thread 3 (process 10993)]#0  0x08053840 in ?? ()
> (gdb) bt
> #0  0x08053840 in ?? ()
> Cannot access memory at address 0x2b
> (gdb)
> #0  0x08053840 in ?? ()
> Cannot access memory at address 0x2b
> (gdb) thread 1
> [Switching to thread 1 (process 9829)]#0  0x080485df in a (p=0x0)
>    at threadcore.c:34
> 34      in threadcore.c
> (gdb) bt
> #0  0x080485df in a (p=0x0) at threadcore.c:34
> #1  0x080485bc in main () at threadcore.c:21
> (gdb) thread 2
> [Switching to thread 2 (process 1267)]#0  0xbf5ff9d0 in ?? ()
> (gdb) bt
> #0  0xbf5ff9d0 in ?? ()
> Cannot access memory at address 0x2b
> (gdb) q
> sh-2.05b#
> 
> 
> The problem is with the same glibc and gdb , Redhat 9 linux 2.4.20-8
> does  give me complete information of all the threads in the "info
> threads" command.
> Having read similar problems on various mailing lists , i believe the
> only difference is redhat 9 has patched its kernel with NTPL or
> debugging support for linux in the kernel.
> 
> Wanted to confirm if it this correct .

I really have no idea about this problem.

> My question
> ------------------
> 
> Someone would say move to 2.6 kernel and a different glibc,But with
> custom applications at stake .I can't take that risk as yet .So i
> would want an NTPL patch for 2.4.28 kernel
> Where do i get it ? Please do respond .

Last time I saw an NPTL patch, it was for something like 2.4.21 patched
with O(1) scheduler. I bet you'll have a hard time merging those together
in 2.4.28. It is also possible that core dumps don't look the same. I
have in mind some old changes about thread core dumps, but that's too
far away to say anything reliable on the subject. Check that your core
files are of the same sizes between NPTL and no-NPTL kernels.

Alternatively, you could try RHEL3's kernel (2.4.21) which has all those
things and which is still supported.

Regards,
Willy

Re: NPTL patch for linux 2.4.28

[Syed Ahemed]

 Thanks for the answer , I have already checked the core files size
diff which was surprising in a way.The corefile on linux 2.4.28 (which
actually shows less information than redhat) is bigger than redhat's
2.4.20-8 system core file.
Which brings me to the point that it has to be the generation of
corefiles and as a result lack of debugging support in 2.4.28 that is
causing the problem ( With or without NPTL is what i am out to find
out.

Getting RHEL's source ( http://lkml.org/lkml/2005/3/21/380 ) was an
idea i thought about but then a download of the RHEL source from the
following location was denied .
http://download.fedora.redhat.com/pub/fedora/linux/core/1/SRPMS/  and
the rpmfind site.
(Guess need to be a paid subscriber for that right ?)

Apart from the fact that am relying on a "free " patch (even if that
means i have to spend time forward porting it to 2.4.28 ) .I cannot go
the RHEL way for fear of having to port or debug custom applications
written on 2.4.28 .

I totally understand the fact that 2.4.28 does rarely have support for
patches and updates relative to the more active 2.4.20 or 2.6 kernel
,I still wonder why there aren't any NPTL patches available in the
non-redhat sites for kernels like 2.4.21 or more .
Please point me to NPTL patch location or the kernel SRPM if you could.

Regards
Azhar



On 3/14/07, Willy Tarreau <w@1wt.eu> wrote:
> On Wed, Mar 14, 2007 at 05:49:22AM +0530, Syed Ahemed wrote:
> > Hello all.
> > I have a tricky problem on  hand and a straight forward question.
> >
> > Tricky problem:
> > ---------------------
> > While debugging a simple multithreaded application using gdb linux
> > 2.4.28 , i noticed the thread that has crashed after sigsegv has
> > complete information on the gdb (both  address and function at the
> > time of crash ) .But the other threads that are in wait state (
> > executing glibc functions at the time of crash ) just has the address
> > but not the function name as shown below.
> >
> >
> > sh-2.05b# ./gdb a.out /mnt/cf/engg_files/core_files/
> > a.out.1173437318.core.5312   a.out.1173453940.core.9829
> > a.out.1173438125.core.16016  lost+found
> > a.out.1173438881.core.18721
> > <f/engg_files/core_files/a.out.1173453940.core.9829
> > GNU gdb 6.3
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db
> > library
> > "/lib/libthread_db.so.1".
> >
> > warning: exec file is newer than core file.
> > Core was generated by `./a.out'.
> > Program terminated with signal 11, Segmentation fault.
> > Reading symbols from /lib/libpthread.so.0...done.
> > Loaded symbols for /lib/libpthread.so.0
> > Reading symbols from /lib/libc.so.6...done.
> > Loaded symbols for /lib/libc.so.6
> > Reading symbols from /opt/lib/ld-linux.so.2...done.
> > Loaded symbols for /opt//lib/ld-linux.so.2
> > #0  0x080485df in a (p=0x0) at threadcore.c:34
> > 34      threadcore.c: No such file or directory.
> >        in threadcore.c
> > (gdb) info threads
> >  3 process 10993  0x08053840 in ?? ()
> >  2 process 1267  0xbf5ff9d0 in ?? ()
> > * 1 process 9829  0x080485df in a (p=0x0) at threadcore.c:34
> > (gdb) thread 3
> > [Switching to thread 3 (process 10993)]#0  0x08053840 in ?? ()
> > (gdb) bt
> > #0  0x08053840 in ?? ()
> > Cannot access memory at address 0x2b
> > (gdb)
> > #0  0x08053840 in ?? ()
> > Cannot access memory at address 0x2b
> > (gdb) thread 1
> > [Switching to thread 1 (process 9829)]#0  0x080485df in a (p=0x0)
> >    at threadcore.c:34
> > 34      in threadcore.c
> > (gdb) bt
> > #0  0x080485df in a (p=0x0) at threadcore.c:34
> > #1  0x080485bc in main () at threadcore.c:21
> > (gdb) thread 2
> > [Switching to thread 2 (process 1267)]#0  0xbf5ff9d0 in ?? ()
> > (gdb) bt
> > #0  0xbf5ff9d0 in ?? ()
> > Cannot access memory at address 0x2b
> > (gdb) q
> > sh-2.05b#
> >
> >
> > The problem is with the same glibc and gdb , Redhat 9 linux 2.4.20-8
> > does  give me complete information of all the threads in the "info
> > threads" command.
> > Having read similar problems on various mailing lists , i believe the
> > only difference is redhat 9 has patched its kernel with NTPL or
> > debugging support for linux in the kernel.
> >
> > Wanted to confirm if it this correct .
>
> I really have no idea about this problem.
>
> > My question
> > ------------------
> >
> > Someone would say move to 2.6 kernel and a different glibc,But with
> > custom applications at stake .I can't take that risk as yet .So i
> > would want an NTPL patch for 2.4.28 kernel
> > Where do i get it ? Please do respond .
>
> Last time I saw an NPTL patch, it was for something like 2.4.21 patched
> with O(1) scheduler. I bet you'll have a hard time merging those together
> in 2.4.28. It is also possible that core dumps don't look the same. I
> have in mind some old changes about thread core dumps, but that's too
> far away to say anything reliable on the subject. Check that your core
> files are of the same sizes between NPTL and no-NPTL kernels.
>
> Alternatively, you could try RHEL3's kernel (2.4.21) which has all those
> things and which is still supported.
>
> Regards,
> Willy
>
>


-- 
Azhar khan

I'm afraid that I've seen too many people fix bugs by looking at
debugger output, and that almost inevitably leads to fixing the
symptoms rather than the underlying problems.
	
--Linus

Re: NPTL patch for linux 2.4.28

[Peter Zijlstra]

On Thu, 2007-03-15 at 03:14 +0530, Syed Ahemed wrote:

> Getting RHEL's source ( http://lkml.org/lkml/2005/3/21/380 ) was an
> idea i thought about but then a download of the RHEL source from the
> following location was denied .
> http://download.fedora.redhat.com/pub/fedora/linux/core/1/SRPMS/  and
> the rpmfind site.
> (Guess need to be a paid subscriber for that right ?)

Strangely enough you try to download Fedora Core SRPMs whilst you speak
of RHEL. Try this one:

ftp://ftp.redhat.com/pub/redhat/linux/enterprise/3/en/os/i386/SRPMS/kernel-2.4.21-4.EL.src.rpm

Also, CentOS would have similar sources. Google could have informed you
on that.

> I still wonder why there aren't any NPTL patches available in the
> non-redhat sites for kernels like 2.4.21 or more .

Because most people, especially the ones on this mailing list have moved
on to 2.6 quite some time ago. May I suggest you do the same?

Re: NPTL patch for linux 2.4.28

[Willy Tarreau]

On Thu, Mar 15, 2007 at 08:53:06AM +0100, Peter Zijlstra wrote:
> On Thu, 2007-03-15 at 03:14 +0530, Syed Ahemed wrote:
> 
> > Getting RHEL's source ( http://lkml.org/lkml/2005/3/21/380 ) was an
> > idea i thought about but then a download of the RHEL source from the
> > following location was denied .
> > http://download.fedora.redhat.com/pub/fedora/linux/core/1/SRPMS/  and
> > the rpmfind site.
> > (Guess need to be a paid subscriber for that right ?)
> 
> Strangely enough you try to download Fedora Core SRPMs whilst you speak
> of RHEL. Try this one:
> 
> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/3/en/os/i386/SRPMS/kernel-2.4.21-4.EL.src.rpm
> 
> Also, CentOS would have similar sources. Google could have informed you
> on that.
> 
> > I still wonder why there aren't any NPTL patches available in the
> > non-redhat sites for kernels like 2.4.21 or more .
> 
> Because most people, especially the ones on this mailing list have moved
> on to 2.6 quite some time ago. May I suggest you do the same?

... or they stick to 2.4 for specific uses and do not need NPTL at all, which
came late in the development cycle.

Regards,
Willy

Re: NPTL patch for linux 2.4.28

[Syed Ahemed]

Point taken Sir , Change to 2.6 is inevitable i believe ....Allthough
i shall give the RHEL patch port to 2.4.28 a try over the weekend :-)
Thanks  a lot Willy and Peter for the help .

On 3/15/07, Willy Tarreau <w@1wt.eu> wrote:
> On Thu, Mar 15, 2007 at 08:53:06AM +0100, Peter Zijlstra wrote:
> > On Thu, 2007-03-15 at 03:14 +0530, Syed Ahemed wrote:
> >
> > > Getting RHEL's source ( http://lkml.org/lkml/2005/3/21/380 ) was an
> > > idea i thought about but then a download of the RHEL source from the
> > > following location was denied .
> > > http://download.fedora.redhat.com/pub/fedora/linux/core/1/SRPMS/  and
> > > the rpmfind site.
> > > (Guess need to be a paid subscriber for that right ?)
> >
> > Strangely enough you try to download Fedora Core SRPMs whilst you speak
> > of RHEL. Try this one:
> >
> > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/3/en/os/i386/SRPMS/kernel-2.4.21-4.EL.src.rpm
> >
> > Also, CentOS would have similar sources. Google could have informed you
> > on that.
> >
> > > I still wonder why there aren't any NPTL patches available in the
> > > non-redhat sites for kernels like 2.4.21 or more .
> >
> > Because most people, especially the ones on this mailing list have moved
> > on to 2.6 quite some time ago. May I suggest you do the same?
>
> ... or they stick to 2.4 for specific uses and do not need NPTL at all, which
> came late in the development cycle.
>
> Regards,
> Willy
>
>


-- 
Azhar khan

I'm afraid that I've seen too many people fix bugs by looking at
debugger output, and that almost inevitably leads to fixing the
symptoms rather than the underlying problems.
	
--Linus

Re: NPTL patch for linux 2.4.28

[Syed Ahemed]

Hello Willy ,

As an afterthought , You had seamlessly backported 2.4.32 and other
patches for me sometime back.Please see article below.
http://lwn.net/Articles/169722/

I could provide you with patch rejects and any other help from the
2.4.20-8 patch (rpm2cpio'ed  redhat source rpm) to see if we can work
together and provide a patch for other kernel releases too.

As for my problem it wil take some convincing on my part and
feasability study to convince my company to get to 2.6/RHEL
kernel.While that happens i have the time and interest to make this
work ...Sincerly.


Regards
Syed



On 3/15/07, Syed Ahemed <kingkhan@gmail.com> wrote:
> Point taken Sir , Change to 2.6 is inevitable i believe ....Allthough
> i shall give the RHEL patch port to 2.4.28 a try over the weekend :-)
> Thanks  a lot Willy and Peter for the help .
>
> On 3/15/07, Willy Tarreau <w@1wt.eu> wrote:
> > On Thu, Mar 15, 2007 at 08:53:06AM +0100, Peter Zijlstra wrote:
> > > On Thu, 2007-03-15 at 03:14 +0530, Syed Ahemed wrote:
> > >
> > > > Getting RHEL's source ( http://lkml.org/lkml/2005/3/21/380 ) was an
> > > > idea i thought about but then a download of the RHEL source from the
> > > > following location was denied .
> > > > http://download.fedora.redhat.com/pub/fedora/linux/core/1/SRPMS/  and
> > > > the rpmfind site.
> > > > (Guess need to be a paid subscriber for that right ?)
> > >
> > > Strangely enough you try to download Fedora Core SRPMs whilst you speak
> > > of RHEL. Try this one:
> > >
> > > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/3/en/os/i386/SRPMS/kernel-2.4.21-4.EL.src.rpm
> > >
> > > Also, CentOS would have similar sources. Google could have informed you
> > > on that.
> > >
> > > > I still wonder why there aren't any NPTL patches available in the
> > > > non-redhat sites for kernels like 2.4.21 or more .
> > >
> > > Because most people, especially the ones on this mailing list have moved
> > > on to 2.6 quite some time ago. May I suggest you do the same?
> >
> > ... or they stick to 2.4 for specific uses and do not need NPTL at all, which
> > came late in the development cycle.
> >
> > Regards,
> > Willy
> >
> >
>
>
> --
> Azhar khan
>
> I'm afraid that I've seen too many people fix bugs by looking at
> debugger output, and that almost inevitably leads to fixing the
> symptoms rather than the underlying problems.
>
> --Linus
>


-- 
Azhar khan

I'm afraid that I've seen too many people fix bugs by looking at
debugger output, and that almost inevitably leads to fixing the
symptoms rather than the underlying problems.
	
--Linus