Re: 0xffffe002 in ??

[KV Pavuram <kvpavuram@yahoo.co.in>]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/