Euphoria
Ticket #869:
machine level exception in a portable version of dsearch.exw
-
Reported by
SDPringle
Apr 17, 2013
In this portable version of dsearch.exw, the interpreter crashes on Linux with a machine exception when searching for a function that doesn't exist.
http://openeuphoria.org/pastey/212.wc.
If it is opening too many dlls it should create an ex.err file and report that there are too many dlls open.
Details
1. Comment by SDPringle
Sep 02, 2013
There is a better version of this test program. Download it at https://github.com/shawnpringle/euphoriabugger/.
On Linux 32 you can trigger this with:
eui dsearch.ex --lib libkorganizer_interfaces.so foo
2. Comment by mattlewis
Sep 03, 2013
I'm not able to reproduce this. I got some crashes, but it was unrelated to anything like opening too many dlls. One was that it expected some sort of initialization of Qt to have happened, and I got some others where it was calling eu_init stuff from the initialization routines in the libraries.
Could you build a debug version and get the stack trace after the crash?
3. Comment by SDPringle
Feb 12, 2014
I downloaded the 4.0.5 sources and compiled with the options '--debug --final'.
Here is the stack trace gdb gives me:
#0 0xa28ad42c in genl_register () from /usr/lib/libnl-genl-3.so.200
#1 0xa27e639d in ?? () from /usr/lib/libnl.so.1
#2 0xa280ee2d in ?? () from /usr/lib/libnl.so.1
#3 0xa27e3744 in _init () from /usr/lib/libnl.so.1
#4 0xb7fff040 in ?? () from /lib/ld-linux.so.2
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
4. Comment by mattlewis
Feb 12, 2014
Based on my previous trials, it sounds like some library is doing something weird. Does it consistently crash on a particular library?
I tried this again on my system with 4.0.5 and a current build of the structs branch (64-bit) and it does not crash for me.
matt@bratac:~/eu/test/euphoriabugger$ eui dsearch.ex --lib libkorganizer_interfaces.so foo
libkorganizer_interfaces.so: Couldn't open.
Couldn't find foo
Press Enter
matt@bratac:~/eu/test/euphoriabugger$ eui405 dsearch.ex --lib libkorganizer_interfaces.so foo
libkorganizer_interfaces.so: Couldn't open.
Couldn't find foo
Press Enter
I also tried without specifying the library to look at with similar results (except that 4.0.5 can't open most things it found because they're 64-bit libraries).
5. Comment by SDPringle
Feb 12, 2014
Okay, I added logging to dsearch.ex flushing the log as it writes. So, I have determined that the log crashes just after it writes the following filename to the log:
/usr/lib/libnl.so.1.1.4
6. Comment by mattlewis
Feb 12, 2014
The trace back makes sense. It's crashing on the startup code for that library. I don't know what sort of stuff goes on there or what you're supposed to do to properly load it, though the equivalent on my system (libnl-3.so.200, I think) doesn't crash for me.
I don't think this is a bug that euphoria can handle, since it's code within the library that's causing the crash. You could alternatively try using nm and parsing the output of that.
7. Comment by SDPringle
Feb 12, 2014
I have added an option to dsearch so I can exclude libraries and I find if I exclude those trouble libraries, the problem goes away.
I am marking this invalid. I believe this is a problem with the library init functions stepping on each other's data and not the EUPHORIA implementation itself.