[coldfire-gnu-discuss] systemcall select() seems to overwrite variables on the stack

Andreas Wehrmann a.wehrmann at centersystems.com
Tue Oct 12 06:33:23 UTC 2010


  A colleague and I managed to write a test program that reproduces a 
problem related to calling select(). In the test program, when compiled 
with optimization (-O2), the second call to select() never returns, not 
even after the timeout. This seems to be a very delicate problem, 
because if I change anything in the program it might work again. In this 
special case: when I remove the trace after the call to select(), the 
program works (with and without optimization enabled).
Because of this, I attached the assembler output from the compiler, plus 
a readable form and of course the source code of the test program + the 
makefile used to build the program.
I hope this helps.

Best regards,
Andreas Wehrmann

On 10/11/2010 04:14 PM, Andreas Wehrmann wrote:
> 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 --------------
An embedded and charset-unspecified text was scrubbed...
Name: Makefile
URL: <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/attachments/20101012/03232c27/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_select.c
Type: text/x-csrc
Size: 1865 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/attachments/20101012/03232c27/attachment.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_select_O2.s
URL: <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/attachments/20101012/03232c27/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_select_O2_readable.output
URL: <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/attachments/20101012/03232c27/attachment-0002.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_select_unoptimized.s
URL: <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/attachments/20101012/03232c27/attachment-0003.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_select_unoptimized_readable.output
URL: <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/attachments/20101012/03232c27/attachment-0004.ksh>


More information about the coldfire-gnu-discuss mailing list