Issue115

Title Segm. fault on shared library import
Priority bug Status resolved
Superseder Nosy List kayhayen, smil3y
Assigned To kayhayen Keywords wrong_execution

Created on 2013-11-30.20:19:26 by smil3y, last changed by kayhayen.

Files
File name Uploaded Type Edit Remove
config.py smil3y, 2013-11-30.22:43:01 text/x-python
gdb.txt smil3y, 2013-11-30.22:42:33 text/plain
trace.txt smil3y, 2013-11-30.20:22:05 text/plain
Messages
msg528 (view) Author: kayhayen Date: 2013-12-05.14:07:50
Released as 0.4.7
msg527 (view) Author: smil3y Date: 2013-12-01.13:00:42
Fix confirmed!
msg525 (view) Author: kayhayen Date: 2013-12-01.12:28:42
Fix is in factory, I am preparing a pre-release with it.

The bug was triggered by a rich comparison of types, i.e. "==" when a module or 
package embedds other ones. The patching was not safe against doing it twice and 
patched itself to call itself in an infinite loop.

Thanks for the report and help in reproducing this one. Quite tough. I am about 
to make a new release of Nuitka anyway and this will be included, so I am not 
making it a hotfix.
msg523 (view) Author: kayhayen Date: 2013-11-30.23:05:32
Can you email me instructions how to check your project out and the exact build 
instructions that lead to the crash.

This is most likely a corruption bug of some sorts, where I will have to reduce 
the test case myself. Nothing looks like this should exist. Luckily these are 
rare, and lets make it even more so.
msg522 (view) Author: smil3y Date: 2013-11-30.22:42:33
Ok, gdb trace attached with the library build with "--trace-execution".
The strange thing is that it segmentation faults when I create a "conf"
object from ConfigParser. I will attach my config module which I just
renamed from configparser to config to try and see if it is a namespace
clash or something like that which didn't helped.
msg521 (view) Author: kayhayen Date: 2013-11-30.22:21:12
That's actually great information already.

Python3 and wrong version were wild guesses only. So it's types being compared. 
You can also do a "--trace-execution" during translation, which will output the 
source code line before crash. 

That ought to help potentially even more.

The function code seems pretty innocent. It just switches arguments with 
compiled types to ones with built-in types, which shouldn't pose an issue at all 
to anything.

Maybe this helps you to reduce this to a test case. Let me know.

Thanks for the report,
Kay
msg520 (view) Author: smil3y Date: 2013-11-30.22:02:13
Oh, and btw - I have only Python version 2.7.6 installed.
Python version 3.x.x is not present and the library is
being imported into the same version it was built with.
msg519 (view) Author: smil3y Date: 2013-11-30.21:59:41
Hello,

It's my first time working with gdb and I am not an expert
in debugging I must say but here is what I get after running
python and importing the shared library:

Program received signal SIGSEGV, Segmentation fault.
0xb79ae8a7 in _type_tp_richcompare(_object*, _object*, int) () from ./libspm.so

I made a quick search and here is the commit that introduces
_type_tp_richcompare:
https://bitbucket.org/kayhayen/nuitka/commits/bc4947c9fba9fb0e16bef6b9da9d0a7187
7ec959

I hope this helps.
msg518 (view) Author: kayhayen Date: 2013-11-30.21:35:38
Hello,

in order to debug it, please use "--debug", which will detoriate performance, 
and see if you get an assertion violated. If not, please run in "gdb", e.g. "gdb 
python", import your module there, and report the crash stack.

Using the wrong Python version is a known source of problems. Loading e.g. a 
shared library created for 3.2 under 3.3 may cause issues and goes undetected it 
seems.
msg517 (view) Author: smil3y Date: 2013-11-30.20:19:26
After building a shared library from a simple file with only
relative imports in it to see how it goes, upon importing the
module (library) generated a segmentation fault is triggered.

The trace is attached, I've used IPython and strace for the
purpose of debugging this. I've attempted to build with
Nuitka 0.4.6.3 and the latest develop (factory is broken
right now and I have not looked into fixing it, possible
sys.path issue or typo). I have tried to build all standard
modules into the library with "--recurse-stdlib" but that
didn't helped either.

My project is public so there is no problem with sharing it,
if you need more info I will provide it. Cheers!
History
Date User Action Args
2013-12-05 14:07:50kayhayensetstatus: testing -> resolved
messages: + msg528
2013-12-01 13:00:42smil3ysetmessages: + msg527
2013-12-01 12:28:42kayhayensetstatus: chatting -> testing
priority: critical -> bug
messages: + msg525
2013-11-30 23:05:32kayhayensetmessages: + msg523
2013-11-30 22:43:01smil3ysetfiles: + config.py
2013-11-30 22:42:33smil3ysetfiles: + gdb.txt
messages: + msg522
2013-11-30 22:21:12kayhayensetmessages: + msg521
2013-11-30 22:02:13smil3ysetmessages: + msg520
2013-11-30 21:59:41smil3ysetmessages: + msg519
2013-11-30 21:35:38kayhayensetstatus: unread -> chatting
assignedto: kayhayen
messages: + msg518
keyword: + wrong_execution
nosy: + kayhayen
2013-11-30 20:22:06smil3ysetfiles: + trace.txt
2013-11-30 20:19:26smil3ycreate