PyErr_Format () Seg Faults

Bug #384643 reported by Rick Spencer
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
pygtk (Ubuntu)
Invalid
Low
Unassigned

Bug Description

Binary package hint: python-launchpadlib

this line of code:
toke = credentials.get_request_token(web_root=token_url)

is causing a segmentation fault in the program stored here:
https://code.edge.launchpad.net/~rick-rickspencer3/pm-dashboard/sebified

The line of code seg faulting is currently at Ln 173 of the file LaunchpadUtils.py

To reproduce, check out the code:
bzr branch lp:~rick-rickspencer3/pm-dashboard/sebified

and the run:
$python MainWindow.py

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: python-launchpadlib 0.2~bzr35-0ubuntu1
PackageArchitecture: all
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: python-launchpadlib
Tags: ubuntu-unr
Uname: Linux 2.6.28-11-generic i686

Revision history for this message
Rick Spencer (rick-rickspencer3) wrote :
Revision history for this message
Rick Spencer (rick-rickspencer3) wrote :

I created a minimal repro script to repro the segmentation fault. Naturally the script does not trigger the segmentation fault. However, I can't for the life of me figure out why my code causes a seg fault, and the repro script does not.

I obviously don't expect this to be a high priority bug, but it would be nice to get an exception that gives me at least some sense of why the failure is occuring, rather than a full on crash.

Revision history for this message
Rick Spencer (rick-rickspencer3) wrote :

Ok, the secret to causing the seg fault seems to be that I am running the application UI on a thread, starting gtk.main() in a context like this:
 gtk.gdk.threads_init()
 gtk.gdk.threads_enter()
 gtk.main()
 gtk.gdk.threads_leave()

When I comment out gtk.gdk.threads_enter(), and gtk.gdk.threads_leave() the program does not seg fault.

Revision history for this message
Rick Spencer (rick-rickspencer3) wrote :

Disregard the last comment. In fact, commenting those lines out does not mitigate the seg faults.

Revision history for this message
Rick Spencer (rick-rickspencer3) wrote :

Retargeting here, as the problem seems to be that python is seg faulting while trying to format an error message.

affects: python-launchpadlib (Ubuntu) → pygtk (Ubuntu)
Revision history for this message
Ken VanDine (ken-vandine) wrote :

I suspect a race condition of some sort, if i drop into the debugger it works 100% of the time.

Revision history for this message
Rick Spencer (rick-rickspencer3) wrote :

@Ken: right, that probably is related to the bug in my code, but may or may not be part of this bug which is referring to that fact that python seg faults when trying to print the error (I think).

I'm next to useless for this, but looking at symbols from the core dump:
#0 0x00000000004b0ebf in PyErr_Format ()
#1 0x00000000004a0558 in PyEval_EvalFrameEx ()
#2 0x00000000004a3dae in PyEval_EvalFrameEx ()
#3 0x00000000004a3dae in PyEval_EvalFrameEx ()
#4 0x00000000004a3dae in PyEval_EvalFrameEx ()
#5 0x00000000004a4649 in PyEval_EvalCodeEx ()
#6 0x00000000005329ad in ?? ()
#7 0x000000000041d3bd in PyObject_Call ()
#8 0x0000000000424f48 in ?? ()
#9 0x000000000041d3bd in PyObject_Call ()
#10 0x000000000049cd46 in PyEval_CallObjectWithKeywords ()
#11 0x00000000004d3b3d in ?? ()
#12 0x00007fec5fbcd3ba in start_thread () from /lib/libpthread.so.0
#13 0x00007fec5f095fcd in clone () from /lib/libc.so.6
#14 0x0000000000000000 in ?? ()
 it appears that the function "PyErr_Format ()" is crashing.

summary: - credentials.get_request_token function causes a segmentation fault
+ PyErr_Format () Seg Faults
Revision history for this message
Rick Spencer (rick-rickspencer3) wrote :

Note that the bug in my python code was that I initialized threads *after* creating them, causing a bit of havoc.

So the program does not seg fault. However, I am not certain if this invalidates the bug. It seems to me that python should throw an exception, not seg fault. It especially should not seg fault when trying to create an error message.

Revision history for this message
Sebastien Bacher (seb128) wrote :

there is no obvious way from pygtk to determine that an init function which will be required by some later use has not been called and upstream already stated they would not put effort on dealing better with such coding error, I guess the request is still a valid one but low on the list and it's probably not going to be worked any time soon either

Changed in pygtk (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
importance: Undecided → Low
Revision history for this message
Pedro Villavicencio (pedro) wrote :

Thanks for the report Rick Spencer , It has been a long time without any comment or a duplicate in this bug report and It is possible that the bug has been fixed. May you please try to reproduce it with the latest Stable Release of Ubuntu the Natty Narwhal and add the respective comments to the report? You can learn how to get that release at http://www.ubuntu.com/download . Thanks again and we appreciate your help.

Changed in pygtk (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
status: New → Incomplete
Revision history for this message
Rick Spencer (rick-rickspencer3) wrote :

This has been so long since I touched it, and I don't have the time to follow up now. Let us drop this from our radar. If someone else encounters it, they can reopen.

Changed in pygtk (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.