Re: 0xffffe002 in ??

From: Denis Vlasenko
Date: Wed Jun 22 2005 - 02:52:35 EST

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/
b7f64000 8K rwxp /app/uclibc-0.9.26/lib/
b7f66000 16K rwxp [ anon ]
b7f6a000 8K r-xp /app/uclibc-0.9.26/lib/
b7f6c000 4K rwxp /app/uclibc-0.9.26/lib/
b7f6e000 4K rwxp [ anon ]
b7f6f000 16K r-xp /app/uclibc-0.9.26/lib/
b7f73000 4K rwxp /app/uclibc-0.9.26/lib/
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at