Bug 352431 - Dia crashes on startup while importing pyexpat
Dia crashes on startup while importing pyexpat
Status: CLOSED DUPLICATE of bug 363771
Product: Fedora
Classification: Fedora
Component: dia (Show other bugs)
7
All Linux
low Severity high
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
http://bugzilla.gnome.org/show_bug.cg...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-25 10:59 EDT by Hans Breuer
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-02 09:45:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 457828 None None None Never

  None (edit)
Description Hans Breuer 2007-10-25 10:59:24 EDT
An example bug report is below. I'm pretty sure the bug is in the distribution,
not in Dia itself. Apparently it only crashes when Dia is importing pyexpat, not
when it is done in a standalone Python. So far this bug is only reported for Dia
running on Fedora 7

There is a workaround in Dia SVN to just not import pyexpat on Dia start-up, but
when it is needed.

Version: @0.96.1@

What were you doing when the application crashed?
starting up dia


Distribution: Fedora release 7 (Moonshine)
Gnome Release: 2.18.3 2007-07-02 (Red Hat, Inc)
BugBuddy Version: 2.18.0

System: Linux 2.6.20-1.2952.fc6 #1 SMP Wed May 16 18:59:18 EDT 2007 i686
X Vendor: The X.Org Foundation
X Vendor Release: 10300000
Selinux: No
Accessibility: Disabled
GTK+ Theme: Clearlooks
Icon Theme: Clearlooks

Memory status: size: 29466624 vsize: 29466624 resident: 13156352 share: 9539584
rss: 13156352 rss_rlim: 4294967295
CPU usage: start_time: 1184726444 rtime: 11 utime: 9 stime: 2 cutime:0 cstime:
0 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/dia'

(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1208621344 (LWP 4148)]
(no debugging symbols found)
0x001d8402 in __kernel_vsyscall ()
#0  0x001d8402 in __kernel_vsyscall ()
#1  0x00bb5d13 in __waitpid_nocancel () from /lib/libpthread.so.0
#2  0x00162a46 in ?? () from /usr/lib/libgnomeui-2.so.0
#3  <signal handler called>
#4  0x001d8402 in __kernel_vsyscall ()
#5  0x00f57fa0 in raise () from /lib/libc.so.6
#6  0x00f598b1 in abort () from /lib/libc.so.6
#7  0x00f513ce in __assert_fail () from /lib/libc.so.6
#8  0x02f8b21f in PyString_FromString () from /usr/lib/libpython2.5.so.1.0
#9  0x02fde65d in PyModule_AddStringConstant () from
/usr/lib/libpython2.5.so.1.0
#10 0x00e89bb3 in initpyexpat () from
/usr/lib/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#11 0x02fdb6c8 in _PyImport_LoadDynamicModule () from
/usr/lib/libpython2.5.so.1.0
#12 0x02fd90fe in ?? () from /usr/lib/libpython2.5.so.1.0
#13 0x02fd9893 in ?? () from /usr/lib/libpython2.5.so.1.0
#14 0x02fd9d7c in ?? () from /usr/lib/libpython2.5.so.1.0
#15 0x02fd9f9f in ?? () from /usr/lib/libpython2.5.so.1.0
#16 0x02fda407 in PyImport_ImportModuleLevel () from
/usr/lib/libpython2.5.so.1.0
#17 0x02fbf614 in ?? () from /usr/lib/libpython2.5.so.1.0
#18 0x02f7a11d in PyCFunction_Call () from /usr/lib/libpython2.5.so.1.0
#19 0x02f47ee7 in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#20 0x02fbfcec in PyEval_CallObjectWithKeywords () from
/usr/lib/libpython2.5.so.1.0
#21 0x02fc2de5 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#22 0x02fc7b2f in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#23 0x02fc7bb3 in PyEval_EvalCode () from /usr/lib/libpython2.5.so.1.0
#24 0x02fd81cd in PyImport_ExecCodeModuleEx () from
/usr/lib/libpython2.5.so.1.0
#25 0x02fd87a4 in ?? () from /usr/lib/libpython2.5.so.1.0
#26 0x02fd9893 in ?? () from /usr/lib/libpython2.5.so.1.0
#27 0x02fd9d7c in ?? () from /usr/lib/libpython2.5.so.1.0
#28 0x02fd9fe6 in ?? () from /usr/lib/libpython2.5.so.1.0
#29 0x02fda407 in PyImport_ImportModuleLevel () from
/usr/lib/libpython2.5.so.1.0
#30 0x02fbf614 in ?? () from /usr/lib/libpython2.5.so.1.0
#31 0x02f7a11d in PyCFunction_Call () from /usr/lib/libpython2.5.so.1.0
#32 0x02f47ee7 in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#33 0x02fbfcec in PyEval_CallObjectWithKeywords () from
/usr/lib/libpython2.5.so.1.0
#34 0x02fc2de5 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#35 0x02fc7b2f in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#36 0x02fc7bb3 in PyEval_EvalCode () from /usr/lib/libpython2.5.so.1.0
#37 0x02fd81cd in PyImport_ExecCodeModuleEx () from
/usr/lib/libpython2.5.so.1.0
#38 0x02fd87a4 in ?? () from /usr/lib/libpython2.5.so.1.0
#39 0x02fd9893 in ?? () from /usr/lib/libpython2.5.so.1.0
#40 0x02fd9d7c in ?? () from /usr/lib/libpython2.5.so.1.0
#41 0x02fd9f9f in ?? () from /usr/lib/libpython2.5.so.1.0
#42 0x02fda407 in PyImport_ImportModuleLevel () from
/usr/lib/libpython2.5.so.1.0
#43 0x02fbf614 in ?? () from /usr/lib/libpython2.5.so.1.0
#44 0x02f7a11d in PyCFunction_Call () from /usr/lib/libpython2.5.so.1.0
#45 0x02fc7024 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#46 0x02fc7b2f in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#47 0x02fc7bb3 in PyEval_EvalCode () from /usr/lib/libpython2.5.so.1.0
#48 0x02fe15d6 in ?? () from /usr/lib/libpython2.5.so.1.0
#49 0x02fe168e in PyRun_FileExFlags () from /usr/lib/libpython2.5.so.1.0
#50 0x02fe2d48 in PyRun_SimpleFileExFlags () from /usr/lib/libpython2.5.so.1.0
#51 0x00be7fc5 in dia_plugin_init () from /usr/lib/dia/libpython_plugin.so
#52 0x00ef70d4 in dia_plugin_load () from /usr/lib/dia/libdia.so
#53 0x00ef754d in dia_register_plugin () from /usr/lib/dia/libdia.so
#54 0x00ef6ceb in ?? () from /usr/lib/dia/libdia.so
#55 0x00ef7826 in dia_register_plugins () from /usr/lib/dia/libdia.so
#56 0x0806cb75 in app_init ()
#57 0x0809dd52 in main ()
Comment 1 Hans de Goede 2007-10-28 11:47:56 EDT
Strange,

I just tried reproducing this on my F-7 i386 test machine and there it works fine.

Judging from the backtrace this is not happening on an x86_64 machine, but ona 
32 bit machine, maybe a powerpc machine?

Gnome bugzilla does have quite a few reports, really strange.

I'll try installing all the latest updates and see if that helps in breaking things.
Comment 2 Hans de Goede 2007-10-29 03:29:13 EDT
Installed all the updates, started dia, still works fine. There has to be a
pattern, something all the reporters have / don't have which I don't / do, but what?
Comment 3 Hans Breuer 2007-10-29 17:12:46 EDT
One thing would be to apply the workaround from upstream:

Index: D:/devel/from-svn/dia/ChangeLog
===================================================================
--- D:/devel/from-svn/dia/ChangeLog	(revision 3773)
+++ D:/devel/from-svn/dia/ChangeLog	(revision 3774)
@@ -1,5 +1,9 @@
 2007-09-08  Hans Breuer  <hans@breuer.org>
 
+	* plug-ins/python/doxrev.py : moved the import of xml.parsers.expat
+	to Parse() so it is not called during start-up. Fixes the start-up
+	crash without understanding what is really causing it, bug #457828
+
 	* plug-ins/python/codegen.py : reset the internal state in 
 	begin_render(). Otherwise the renderer would remember previous 
 	exports. Fixes bug #436311
Index: D:/devel/from-svn/dia/plug-ins/python/doxrev.py
===================================================================
--- D:/devel/from-svn/dia/plug-ins/python/doxrev.py	(revision 3773)
+++ D:/devel/from-svn/dia/plug-ins/python/doxrev.py	(revision 3774)
@@ -324,9 +324,9 @@
 			break
 	return o
 
-import xml.parsers.expat
 # a SAX based parser turning XML tags into Python code
 def Parse (sData) :
+	import xml.parsers.expat
 	unhandled = {}
 	ctx = []
 	classes = []
Comment 4 Hans de Goede 2007-10-30 03:34:19 EDT
Yes, I already saw that "fix", but I would much rather find out whats going on
then paper over the problem. I'll try to reproduce it with a clean F-7 install
today.
Comment 5 Hans de Goede 2007-10-31 15:20:42 EDT
Tried a clean F-7 install today, works fine. GRRR.

For now I'll leave this open and not apply the workaround as then the workaround
will end up in F-8 too, and I first want to see if F-8 gets these same
backtraces. Soory for all the extra BZ spam this will cause upstream.

Please let me know if you get any F-8 / development version reports about this
(F-8 will be released 8 november). I want to know if this hits F-8 too, then
I'll sync some more time into it, if it doesn't I'll just add the workaround to
stop this from hapening on F-7.

In the mean time, could you ask some of the reports if:
1) This is 100% reproducable
2) If this still happens after applying all available Fedora 7 updates?

Maybe this just happens with a mixture of some but not all Fedora 7 updates?
Comment 6 Hans Breuer 2007-10-31 16:13:44 EDT
Just tried to ask by adding a comment to the original bug report
[http://bugzilla.gnome.org/show_bug.cgi?id=457828] 
apparently the closed bug report does not create any emails to the reporters.

BTW: the patch is an improvement in itself, because it delays the loading of
pyexpat to when it is needed. It is not just a work-around for the crash.

BTW: if you are looking at all the dupes found by the simple dupfinder it does
not only list bugs reported against Dia:

http://bugzilla.gnome.org/dupfinder/simple-dup-finder.cgi?id=457828

Maybe there are original reporters listening.
Comment 7 Hans de Goede 2007-11-02 09:45:53 EDT
Hmm, looking at:
http://bugzilla.gnome.org/dupfinder/simple-dup-finder.cgi?id=457828

This is really nasty as gedit and rythmbox are crashing with the same problem
for some Fedora users with both FC-6 and F-7 too.

So I've filed a more generic bug for this, bug 363771. I'm closing this as a
dupe of that.


*** This bug has been marked as a duplicate of 363771 ***

Note You need to log in before you can comment on or make changes to this bug.