This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Python stackdump on "succesful" exit after import of python-requests


I realized that for me, the "work-around" to use python3 was not practical, so I am back to analyzing this problem... And not making much progress. Some help/assistance would be appreciated!

I got the following traceback:

(gdb) r generator.py libvirt /usr/share/libvirt/api/libvirt-api.xml
Starting program: /usr/bin/python generator.py libvirt /usr/share/libvirt/api/libvirt-api.xml
[New Thread 7028.0xb4]
[New Thread 7028.0x1998]
[New Thread 7028.0x1070]
[New Thread 7028.0x15d8]
[New Thread 7028.0x1d38]

Found 406 functions in /usr/share/libvirt/api/libvirt-api.xml
Found 0 functions in libvirt-override-api.xml
Generated 338 wrapper functions

Program received signal SIGABRT, Aborted.
0x66b73de4 in Py_Exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
1780        exit(sts);
(gdb) bt
#0  0x66b73de4 in Py_Exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
#1  0x76e8e091 in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/SYSTEM32/KERNELBASE.dll
#2  0x76e8dff2 in WaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/KERNELBASE.dll
#3  0x610f2730 in sig_send(_pinfo*, siginfo_t&, _cygtls*)@12 (p=p@entry=0x60fd0000, si=..., tls=tls@entry=0x0) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/sigproc.cc:716
#4  0x610ef4cc in _pinfo::kill(siginfo_t&)@8 (this=0x60fd0000, si=...) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:252
#5  0x610ef9d8 in kill0 (pid=pid@entry=7028, si=...) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:303
#6  0x610efbb2 in kill (sig=sig@entry=6, pid=7028) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:312
#7  raise (sig=sig@entry=6) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:288
#8  0x610efe79 in abort () at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:375
#9  0x6deb43c1 in cyggcc_s-1!.deregister_frame_info_bases () from /usr/bin/cyggcc_s-1.dll
#10 0x6e1e10e2 in ?? () from /usr/bin/cygexpat-1.dll
#11 0x61028bb7 in per_module::run_dtors (this=0x6130d980) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dll_init.cc:81
#12 dll::run_dtors (this=0x6130d978) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dll_init.h:72
#13 dll_global_dtors () at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dll_init.cc:53
#14 0x6118d64d in __call_exitprocs (code=code@entry=0, d=d@entry=0x0) at /usr/src/debug/cygwin-2.4.1-1/newlib/libc/stdlib/__call_atexit.c:118
#15 0x6114ae88 in exit (code=0) at /usr/src/debug/cygwin-2.4.1-1/newlib/libc/stdlib/exit.c:66
#16 0x61006e79 in cygwin_exit (n=0) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dcrt0.cc:1337
#17 0x610ebf85 in _sigfe () at sigfe.s:38
#18 0x66b73de4 in Py_Exit (sts=sts@entry=0) at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
#19 0x66ba5281 in handle_system_exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1152
#20 0x66b7413e in handle_system_exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1193
#21 PyErr_PrintEx (set_sys_last_vars=set_sys_last_vars@entry=1) at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1162
#22 0x66b74bc7 in PyErr_Print () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1065
#23 PyRun_SimpleFileExFlags (fp=<optimized out>, filename=0x60cc5c "generator.py", closeit=1, flags=0x60cb5c) at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:953
#24 0x66b8ae9e in Py_Main (argc=argc@entry=4, argv=argv@entry=0x60cc1c) at /usr/src/debug/python-2.7.10-1/Modules/main.c:640
#25 0x00401750 in main (argc=4, argv=0x60cc1c) at /usr/src/debug/python-2.7.10-1/Modules/python.c:23

I'm used to looking at tracebacks from C++ executables, so most of this feels familiar.

It would appear that deregister_frame_info_bases () (on #9) causes the abort to happen. As far as I have been able to figure out, all of this happens while the instance of Python is being shut down.

This is also not a new problem, as this was apparently already reported in November of 2014:

http://readlist.com/lists/cygwin.com/cygwin/15/75280.html

Unfortunately that thread does not go any further than what is also apparent from my traceback.

Does anybody have suggestions on how to further debug this issue?

Thanks,

Maarten Jacobs

> From: maarten256@hotmail.com
> To: robert.martens@bell.ca; cygwin@cygwin.com
> Subject: RE: Python stackdump on "succesful" exit after import of python-requests
> Date: Sat, 30 Jan 2016 18:21:45 -0500
> 
> Interesting - I had the same issue earlier this week; I worked around it by using python3 instead, which didn't cause the same issue. (I figured it was just me not doing something right).
> 
> Obviously that doesn't explain the behavior but I didn't have time to further investigate the issue with python 2.7.
> 
> I ran into the issue when I was trying to build libvirt-python on Cygwin.
> 
> I'd be curious to know what the real root cause for this abort is.
> 
> Thanks,
> 
> Maarten Jacobs 
> 
> ----------------------------------------
> From: robert.martens@bell.ca
> To: cygwin@cygwin.com
> Subject: Python stackdump on "succesful" exit after import of python-requests
> Date: Fri, 29 Jan 2016 21:38:54 +0000
> 
> 
> Hello,
> I am having a strange issue with Python 2.7 on cygwin.
> Whenever a script of mine imports 'requests' (python-requests installed via cygwin installer), after it closes I get an "Aborted" message and a stack dump.
> 
> This consistently causes the issue:
> $ python
> Python 2.7.10 (default, Jun 1 2015, 18:17:45)
> [GCC 4.9.2] on cygwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import requests
>>>> exit()
> Aborted (core dumped)
> 
> And here is the stackdump
> $ cat python2.7.exe.stackdump
> Stack trace:
> Frame Function Args
> 0028C868 61033A23 (00000244, 0000EA60, 000000A4, 0028C8D8)
> 0028C998 610F27E2 (000000C8, 000000CC, 000000B8, 6111295F)
> 
> This is what gdb says:
> (gdb) r
> Starting program: /usr/bin/python
> [New Thread 8744.0x1ca0]
> [New Thread 8744.0x24f4]
> [New Thread 8744.0x192c]
> [New Thread 8744.0x11f0]
> Python 2.7.10 (default, Jun 1 2015, 18:17:45)
> [GCC 4.9.2] on cygwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import requests
> [New Thread 8744.0x2380]
>>>> quit()
> 
> Program received signal SIGABRT, Aborted.
> 0x65c63de4 in Py_Exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
> 1780 exit(sts);
> (gdb) bt
> #0 0x65c63de4 in Py_Exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
> #1 0x770ff8d1 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/SysWOW64/ntdll.dll
> #2 0x765014b9 in WaitForSingleObjectEx () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
> #3 0x000002f8 in ?? ()
> #4 0x00000000 in ?? ()
> (gdb) continue
> Continuing.
> [New Thread 8744.0x25c4]
> 3 [main] python2.7 8744 cygwin_exception::open_stackdumpfile: Dumping stack trace to python2.7.exe.stackdump
> [Thread 8744.0x24f4 exited with code 34304]
> [Thread 8744.0x25c4 exited with code 34304]
> [Thread 8744.0x2380 exited with code 34304]
> [Thread 8744.0x192c exited with code 34304]
> [Inferior 1 (process 8744) exited with code 0103000]
> 
> Any ideas?
> 
> Thanks,
> Robert Martens
> ADMS
> 
> 
> --
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> 
> --
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> 
 		 	   		  
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]