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

[Andreas Wehrmann]

  Seems like attaching the naked text files was a bad idea, so here the 
zipped version...


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 --------------
A non-text attachment was scrubbed...
Name: test_select.zip
Type: application/zip
Size: 18050 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/attachments/20101012/e1c9d7c7/attachment.zip>