Re: 0xffffe002 in ??

Re: 0xffffe002 in ??

[Robert Hancock]

KV Pavuram wrote:
> I think the threads are going into that strange
> address when they are waiting over an IPC object like
> semaphore or mutex. Atleast i saw a thread come out of
> that strange address immed. after another threads
> released a semaphore!!
> 
> Thanks for the inputs.

We've seen that behavior on Red Hat 9 at work as well. However, when we 
moved up to the Fedora Core 1 2.4.22 kernel (due to some apparent 
futex/NPTL bugs in the RH9 kernel) we noticed that the correct pthread 
call was listed in the stack trace.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

0xffffe002 in ??

[KV Pavuram]

I am running a multithreaded application on Linux 2.4
kernel (RedHat Linux 9).

At some point the program receives a seg. fault and if
i check info threads, using gdb for debug, almost all
the threads are at "0xffffe002 in ??" 

When I switch to each of these tasks, and try x/i for
0xffffe002, cannot access address.

What could be the problem?

Please help.

Regards,
Pav.


		
__________________________________________________________
How much free photo storage do you get? Store your friends 'n family snaps for FREE with Yahoo! Photos http://in.photos.yahoo.com

Re: 0xffffe002 in ??

[Richard B. Johnson]

On Tue, 21 Jun 2005, KV Pavuram wrote:

> I am running a multithreaded application on Linux 2.4
> kernel (RedHat Linux 9).
>
> At some point the program receives a seg. fault and if
> i check info threads, using gdb for debug, almost all
> the threads are at "0xffffe002 in ??"
>

If a number of threads arrive at the same bad address you
should look for some common code that calls through
a function pointer. If you don't have any calls through
pointers, then you may have something corrupting the stack
so that the return address of a called function gets
corrupted. For instance, if the value 0x02e0 was written
beyond array limits in local (stack) data, then when that
function returned it could actually end up 'returning'
to the bad address you discovered.

Although the kernel provided the seg-fault mechanism, this
is not a kernel problem. This is a user-code problem.

> When I switch to each of these tasks, and try x/i for
> 0xffffe002, cannot access address.
>
> What could be the problem?
>
> Please help.
>
> Regards,
> Pav.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: 0xffffe002 in ??

[KV Pavuram]

Hi,

What about the webpage

https://bugzilla.redhat.com/bugzilla/long_list.cgi?buglist=104763

I am a kernel newbie, so I couldnt catch what is being
explained in the page though. But i do have
pthread_cond_wait in my code that are called too
often.

Regards,
Pav.

--- "Richard B. Johnson" <linux-os@analogic.com>
wrote:

> On Tue, 21 Jun 2005, KV Pavuram wrote:
> 
> > I am running a multithreaded application on Linux
> 2.4
> > kernel (RedHat Linux 9).
> >
> > At some point the program receives a seg. fault
> and if
> > i check info threads, using gdb for debug, almost
> all
> > the threads are at "0xffffe002 in ??"
> >
> 
> If a number of threads arrive at the same bad
> address you
> should look for some common code that calls through
> a function pointer. If you don't have any calls
> through
> pointers, then you may have something corrupting the
> stack
> so that the return address of a called function gets
> corrupted. For instance, if the value 0x02e0 was
> written
> beyond array limits in local (stack) data, then when
> that
> function returned it could actually end up
> 'returning'
> to the bad address you discovered.
> 
> Although the kernel provided the seg-fault
> mechanism, this
> is not a kernel problem. This is a user-code
> problem.
> 
> > When I switch to each of these tasks, and try x/i
> for
> > 0xffffe002, cannot access address.
> >
> > What could be the problem?
> >
> > Please help.
> >
> > Regards,
> > Pav.
> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.12 on an i686 machine
> (5537.79 BogoMips).
>   Notice : All mail here is now cached for review by
> Dictator Bush.
>                   98.36% of all statistics are
> fiction.
> 



	

	
		
__________________________________________________________
Free antispam, antivirus and 1GB to save all your messages
Only in Yahoo! Mail: http://in.mail.yahoo.com

Re: 0xffffe002 in ??

[Denis Vlasenko]

On Tuesday 21 June 2005 18:38, Richard B. Johnson wrote:
> On Tue, 21 Jun 2005, KV Pavuram wrote:
> 
> > I am running a multithreaded application on Linux 2.4
> > kernel (RedHat Linux 9).
> >
> > At some point the program receives a seg. fault and if
> > i check info threads, using gdb for debug, almost all
> > the threads are at "0xffffe002 in ??"

It most likely is something in VDSO:

# pmap 1
1: init
Start         Size Perm Mapping
08048000      704K r-xp /app/bash-3.0-uc/bin/bash
080f8000       28K rwxp /app/bash-3.0-uc/bin/bash
080ff000       40K rwxp [heap]
b7f20000      272K r-xp /app/uclibc-0.9.26/lib/libuClibc-0.9.26.so
b7f64000        8K rwxp /app/uclibc-0.9.26/lib/libuClibc-0.9.26.so
b7f66000       16K rwxp [ anon ]
b7f6a000        8K r-xp /app/uclibc-0.9.26/lib/libdl-0.9.26.so
b7f6c000        4K rwxp /app/uclibc-0.9.26/lib/libdl-0.9.26.so
b7f6e000        4K rwxp [ anon ]
b7f6f000       16K r-xp /app/uclibc-0.9.26/lib/ld-uClibc-0.9.26.so
b7f73000        4K rwxp /app/uclibc-0.9.26/lib/ld-uClibc-0.9.26.so
bff5d000       88K rwxp [ stack ]
ffffe000        4K ---p [vdso]       <====================================
mapped: 1196K    writeable/private: 192K    shared: 0K

> If a number of threads arrive at the same bad address you
> should look for some common code that calls through
> a function pointer. If you don't have any calls through
> pointers, then you may have something corrupting the stack
> so that the return address of a called function gets
> corrupted. For instance, if the value 0x02e0 was written
> beyond array limits in local (stack) data, then when that
> function returned it could actually end up 'returning'
> to the bad address you discovered.

> Although the kernel provided the seg-fault mechanism, this
> is not a kernel problem. This is a user-code problem.

I'm not so sure.
--
vda

Re: 0xffffe002 in ??

[KV Pavuram]

I think the threads are going into that strange
address when they are waiting over an IPC object like
semaphore or mutex. Atleast i saw a thread come out of
that strange address immed. after another threads
released a semaphore!!

Thanks for the inputs.

Pav.
--- Denis Vlasenko <vda@ilport.com.ua> wrote:

> On Tuesday 21 June 2005 18:38, Richard B. Johnson
> wrote:
> > On Tue, 21 Jun 2005, KV Pavuram wrote:
> > 
> > > I am running a multithreaded application on
> Linux 2.4
> > > kernel (RedHat Linux 9).
> > >
> > > At some point the program receives a seg. fault
> and if
> > > i check info threads, using gdb for debug,
> almost all
> > > the threads are at "0xffffe002 in ??"
> 
> It most likely is something in VDSO:
> 
> # pmap 1
> 1: init
> Start         Size Perm Mapping
> 08048000      704K r-xp /app/bash-3.0-uc/bin/bash
> 080f8000       28K rwxp /app/bash-3.0-uc/bin/bash
> 080ff000       40K rwxp [heap]
> b7f20000      272K r-xp
> /app/uclibc-0.9.26/lib/libuClibc-0.9.26.so
> b7f64000        8K rwxp
> /app/uclibc-0.9.26/lib/libuClibc-0.9.26.so
> b7f66000       16K rwxp [ anon ]
> b7f6a000        8K r-xp
> /app/uclibc-0.9.26/lib/libdl-0.9.26.so
> b7f6c000        4K rwxp
> /app/uclibc-0.9.26/lib/libdl-0.9.26.so
> b7f6e000        4K rwxp [ anon ]
> b7f6f000       16K r-xp
> /app/uclibc-0.9.26/lib/ld-uClibc-0.9.26.so
> b7f73000        4K rwxp
> /app/uclibc-0.9.26/lib/ld-uClibc-0.9.26.so
> bff5d000       88K rwxp [ stack ]
> ffffe000        4K ---p [vdso]      
> <====================================
> mapped: 1196K    writeable/private: 192K    shared:
> 0K
> 
> > If a number of threads arrive at the same bad
> address you
> > should look for some common code that calls
> through
> > a function pointer. If you don't have any calls
> through
> > pointers, then you may have something corrupting
> the stack
> > so that the return address of a called function
> gets
> > corrupted. For instance, if the value 0x02e0 was
> written
> > beyond array limits in local (stack) data, then
> when that
> > function returned it could actually end up
> 'returning'
> > to the bad address you discovered.
> 
> > Although the kernel provided the seg-fault
> mechanism, this
> > is not a kernel problem. This is a user-code
> problem.
> 
> I'm not so sure.
> --
> vda
> 
> 



	

	
		
__________________________________________________________
Free antispam, antivirus and 1GB to save all your messages
Only in Yahoo! Mail: http://in.mail.yahoo.com