Segfault in generated code - may be related to user-defined __len__

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Fix lib per issue 111.
2. shedskin rfc822.py
3. make
4. ./rfc822.exe junk.txt

What is the expected output? What do you see instead?

$ ./rfc822.exe junk.txt
From: (None, None)
To: []
Subject: None
Date: None
Segmentation fault (core dumped)

This program parses mail headers, and it works correctly if run on
the provided file "dummyinbox.txt".  But if run on "junk.txt", it segfaults.  
The problem seems to be related to the code for a user-defined
"__len__" function.  

Building a debug version and running under GDB provides some insight:

nagle@user-PC ~/work
$ gdb rfc822_debug.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) run junk.txt
Starting program: /home/nagle/work/rfc822_debug.exe junk.txt
[New thread 3712.0x85c]
Error: dll starting at 0x776f0000 not found.
Error: dll starting at 0x76e80000 not found.
Error: dll starting at 0x776f0000 not found.
Error: dll starting at 0x775f0000 not found.
[New thread 3712.0xdb4]
From: (None, None)
To: []
Subject: None
Date: None

Program received signal SIGSEGV, Segmentation fault.
__rfc822__::__init () at 
/home/nagle/shedskin/shedskin-0.6/shedskin/lib/builtin.hpp:1721
1721    template<class T> inline __ss_int len(T x) { return x->__len__(); }
(gdb) backtrace
#0  __rfc822__::__init () at 
/home/nagle/shedskin/shedskin-0.6/shedskin/lib/builtin.hpp:1721
#1  0x00413fa8 in __shedskin__::__start (initfunc=0x4044b0 
<__rfc822__::__init()>)
    at /home/nagle/shedskin/shedskin-0.6/shedskin/lib/builtin.cpp:2082
#2  0x004015cb in main (argc=1629157965, argv=0x0) at rfc822.cpp:935
(gdb) frame
#0  __rfc822__::__init () at 
/home/nagle/shedskin/shedskin-0.6/shedskin/lib/builtin.hpp:1721
1721    template<class T> inline __ss_int len(T x) { return x->__len__(); }

The Python code applies "len" to an object, intending to invoke the object's 
"__len__" function.  Something may have gone wrong there.  I suspect a 
de-reference of NULL, but I don't see it in the C++ code yet.

What version of the product are you using? On what operating system?

Shed Skin 0.6, Cygwin, 

Please provide any additional information below.

If you run

./rfc822.exe dummyinbox.txt

which runs the program on a valid inbox file, it works.  So the code is correct 
for the normal case, but some error case is failing. 

Original issue reported on code.google.com by na...@animats.com on 10 Nov 2010 at 4:50

Attachments:

• rfc822.py
• rfc822date.py
• junk.txt
• dummyinbox.txt

[GoogleCodeExporter]

thanks! :D 

python rfc822.py junk.txt also crashes, because it tries to do a method call on 
None.

I don't think we want to check each method call for None, so I'm afraid this 
can't be fixed.. it shouldn't really matter though, because we assume a program 
has been tested with CPython, before being compiled with shedskin.

Original comment by mark.duf...@gmail.com on 10 Nov 2010 at 9:40

• Changed state: WontFix

[GoogleCodeExporter]

Ideally, the type inference system should track types which can contain "None" 
values. If it can't determine that "None" is not a possible value, a run time 
check should be generated.  After all, Python programs can catch "NoneType" as 
an exception.

It's also really tough for users to diagnose these errors.  Only programmers 
who know Python, C++, and how to debug machine-generated C++ will be able to 
fix such errors.

However, I can understand deferring work on the issue.  There are higher 
priorities.

(Despite all the issues I'm submitting, quite a bit of library code is now 
working. So far, there's been nothing I haven't been able to work around.) 

Original comment by na...@animats.com on 10 Nov 2010 at 6:06

[GoogleCodeExporter]

Actually, if you're calling a function on a None (null) then the program is 
faulty, not Shed Skin. If you were to write such a program in C++, you'd get a 
segfault in just the same way. What you gain with Shedskin is the ability to 
run your code in Python (slower) and then compile to C++ and machine code for 
speed. You get the best of both worlds, but not in both worlds.

Original comment by fahh...@gmail.com on 10 Nov 2010 at 7:12