systemcall select() seems to overwrite variables on the stack

Andreas Wehrmann a.wehrmann at centersystems.com
Mon Oct 11 14:14:13 UTC 2010


Hello!

I recently came across a very annoying problem.
All this is happening with the latest version of the toolchain
(freescale-coldfire-m68k-linux-gnu-4.4-217.i686.rpm).

I have a multithreading application in which one thread simply calls 
select() in
a loop for a single descriptor and then updates some pointers in case of 
a successful return.
The problem now is: The first parameter to select seems to get destroyed 
in certain cases.
I have included the problematic code as an attachement.

The following happens: At the beginning of the thread, I declare the 
variable "nfds" and
initialize it with (select_fd + 1). But just after the return of 
select() the variable has some useless value (see output). This "useless 
value" is always the same!
The code produces the following output:

...
ldi_dev.c  before select_fd=67 | nfds = 68
ldi_dev.c  before select_fd=67 | nfds = -2141341700
ldi_dev.c  select(): Invalid argument
ldi_dev.c  exiting mainloop

The problem didn't occur with the old toolchain 
(freescale-coldfire-m68k-linux-gnu-4.2-35.i686.rpm).
The problem doesn't occur when compiling without the optimization flag 
(the problematic code gets compiled with -O2 by default).
The code works when using the poll() systemcall.

Since the variable "nfds" is only visible to this particular thread,
this cannot be a multithreading problem.
See the attached screenshot for ddd output.

Now what makes this even more confusing is, that the code seems to work 
when I uncomment the trace just after the call to select()...
I was assuming it might be a libc problem, because I came across this 
mailinglist entry:
http://sources.redhat.com/ml/libc-alpha/2003-06/msg00030.html

I hope it's not a bug in the compiler. We updated to the latest version 
of the toolchain because we ran across some mutex related problems with 
the old version (it seems that sometimes threads don't get waken up when 
they were waiting for a mutex that was locked the moment they tried to 
acquire the lock).

Best regards,
Andreas Wehrmann

-- 
Dipl.-Ing. (FH) Andreas Wehrmann
Software Development
--------------------------------------------------------------
Center Communication Systems GmbH
A-1210 Wien, Ignaz-Köck-Straße 19
Sitz in Wien
FN 796 88p, Firmenbuchgericht Wien
www.centersystems.com

Tel.: +43 (0) 190 199 - 3616
Mobile: +43 (0) 664 884 75916
Fax: +43 (0) 190 199 - 2110
E-Mail: a.wehrmann at centersystems.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: value_change.jpg
Type: image/jpeg
Size: 171314 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/attachments/20101011/385870cc/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldi_dev.c
Type: text/x-csrc
Size: 1988 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/attachments/20101011/385870cc/attachment.c>


More information about the coldfire-gnu-discuss mailing list