Re: 0xffffe002 in ??

[Denis Vlasenko <vda@ilport.com.ua>]

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