Euphoria Ticket #869: machine level exception in a portable version of dsearch.exw

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

Type: Bug Report Severity: Major Category: Interpreter
Assigned To: unknown Status: Invalid Reported Release:
Fixed in SVN #: View VCS: none Milestone: 4.0.6

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.

Search



Quick Links

User menu

Not signed in.

Misc Menu