Re: [coldfire-gnu-discuss] systemcall select() seems to overwrite variables on the stack
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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@xxxxxxxxxxxxxxxxx

Attachment: test_select.zip
Description: Zip archive