Bizarre applet memory and threading issues

While attempting to complete my password management applet, I've run
into a number of problems that result in similar crashes at various
points in program execution.  I'm having trouble defining these crashes
exactly, so I'm submitting this as more of a general question, rather
than searching for an answer to my particular issues.  I'm wondering if
anyone else has encountered this style crash...

b0x0000003f1ead4fbb in pthread_setcanceltype () from /lib/
(gdb) bt
#0  0x0000003f1ead4fbb in pthread_setcanceltype () from /lib/
#1  0x0000003f1ec37600 in __malloc_initialize_hook () from /lib/
#2  0x0000000000000008 in ?? ()
#3  0x0000003f1ea6f6b1 in posix_memalign () from /lib/
#4  0x00002aaaaae3fc4f in _X11TransSocketRead () from
#5  0x00002aaaaae22e43 in _XRead () from /usr/X11R6/lib64/
#6  0x00002aaaaae23e01 in _XReply () from /usr/X11R6/lib64/
#7  0x00002aaaaae1ebb2 in XSync () from /usr/X11R6/lib64/
#8  0x0000000000000060 in ?? ()
#9  0x0000000000000000 in ?? ()
#10 0x0000000000000017 in ?? ()
#11 0x00002aaaab94ec20 in ?? ()
>>> #12 0x0000003f2465d7ea in libgnomeui_module_info_get () from
/usr/X11R6/lib64/  <<<
#13 <signal handler called>
#14 0x0000003f1ea2f729 in raise () from /lib/
#15 0x0000003f1ea30e1e in abort () from /lib/
#16 0x0000003f1ea64f51 in __fsetlocking () from /lib/
#17 0x0000003f1ea6b624 in free () from /lib/
#18 0x0000003f1ea6d0a2 in malloc () from /lib/
#19 0x0000003f20850632 in CRYPTO_malloc () from
#20 0x0000003f208a6431 in EVP_CipherInit_ex () from
#21 0x00002aaaaafef006 in cryptoEncryptData (keyObj=0x7f5210,
inBuf=0x7f1cc0 "tempest", inLen=8, outBuf=0x7f1cc0 "tempest", outLen=6,
    at /home/lemaymd/projects/workspace/gnome-pwmng/src/crypto.c:804
#22 0x00002aaaaafef338 in lockEncryptedData (dat=0x77ce90, key=0x9fb,
    at /home/lemaymd/projects/workspace/gnome-pwmng/src/crypto.c:328
#23 0x00002aaaaaff5d40 in createPwDbEntryWithKey (pwDb=0x7b2010,
acctName=0x7f4490, key=1, userName=0x7f6950, password=0x7f6520,
    err=0x7fffffec7c90) at
#24 0x00002aaaaaff603d in createPwDbEntry (pwDb=0x7b2010,
acctName=0x7f4490, userName=0x7f6950, password=0x7f6520, notes=0x77ce90,
    at /home/lemaymd/projects/workspace/gnome-pwmng/src/pwdb.c:2367
#25 0x000000000040a2f2 in addEntryCb (item=0x786ce0, userDat=Variable
"userDat" is not available.
) at
#26 0x0000003f211235e7 in g_cclosure_marshal_VOID__VOID () from
#27 0x0000003f2110aa89 in g_closure_invoke () from
#28 0x0000003f21121dc8 in g_signal_has_handler_pending () from
#29 0x0000003f21122d37 in g_signal_emit_valist () from
#30 0x0000003f211230f3 in g_signal_emit () from
#31 0x0000003f2374d7ca in gtk_widget_activate () from
#32 0x0000003f236574b0 in gtk_menu_shell_activate_item () from
#33 0x0000003f236577db in gtk_menu_shell_activate_item () from
#34 0x0000003f2364cf6c in gtk_menu_reorder_child () from
#35 0x0000003f236461e6 in gtk_marshal_VOID__UINT_STRING () from
#36 0x0000003f2110ae14 in g_cclosure_new_swap () from
#37 0x0000003f2110aa89 in g_closure_invoke () from
#38 0x0000003f2112190f in g_signal_has_handler_pending () from
#39 0x0000003f21122a9c in g_signal_emit_valist () from
#40 0x0000003f211230f3 in g_signal_emit () from
#41 0x0000003f2374da12 in gtk_widget_activate () from
#42 0x0000003f2374dcf4 in gtk_widget_event () from
#43 0x0000003f236441af in gtk_propagate_event () from
#44 0x0000003f2364454b in gtk_main_do_event () from
#45 0x0000003f23c4c8b5 in gdk_event_get_graphics_expose () from
#46 0x0000003f21529eb5 in g_main_context_dispatch () from
#47 0x0000003f2152bb8e in g_main_context_acquire () from
#48 0x0000003f2152befa in g_main_loop_run () from
#49 0x0000003f1f92eb1f in bonobo_main () from
#50 0x0000003f1f92c604 in bonobo_generic_factory_main_timeout () from
#51 0x0000003f1f92c69d in bonobo_generic_factory_main () from
---Type <return> to continue, or q <return> to quit---

Here's my kernel version: Linux version 2.6.13-rc5-mm1 (root localhost)
(gcc version 4.0.1 (Gentoo 4.0.1, pie-8.7.8)) #11 Wed Sep 7 02:15:33 CDT
I run on an AMD64 machine compiled with 64-bit support and the native
POSIX threading library.

The stacktrace is always very long.  The arrowed (>>> <<<) line is the
common theme among these crashes.  They can occur within one of my
applet-defined functions, or within the main GTK loop outside my
functions.  Eventually, the crash occurs within a pthread routine such
as that at the top of the listing included in this message, or within
"waitpid", deeper within a pthread routine.  The application will crash
outright when it encounters the waitpid variation.  With the problem
shown above, the application will actually hang instead, often hanging
the entire panel as well.  The hanging variety problems always involve a
call to free, whereas the crashing variety typically do not. 
Regardless, the reason I am asking about such obscure and broadly
defined crashes here is that I truly can't define them much more
narrowly.  Here is a bit of context for particular cases where I have
run into trouble:

1. After adding some fields to my applet structure, which extends
PanelApplet and is created directly by the system upon applet load, I
started receiving a "waitpid" crash as soon as the applet was loaded. 
The only way to avert the crash was to pop up a simple GtkDialog at load
time.  This would defer the crash until I attempted to click on the
applet, at which time it would crash with a waitpid error.  By removing
4 bytes of data from the structure, the crash could be avoided
altogether.  It didn't matter which 4 bytes I removed.  Interestingly,
this problem is still present even with the smaller structure on my
Pentium 4 32-bit laptop without native threads.  The applet crashes
immediately with the waitpid error inside libgnomeui_module_info_get.

1. More recently, the particular problem listed above has occurred, and
is associated with invocations of "free".  Originally, it occurred
during an earlier set of delete operations I had defined for various
objects in my system, but I removed those operations temporarily,
(creating memory leaks) to no avail, since the system still crashes at
the point shown above, which occurs soon after the original delete
operations normally would have.  So, I believe this problem is somehow
linked to free and not any particular feature of my code.  Don't get
hung up on the fact that free is called within OpenSSL.  In the original
delete operations g_free was called directly.

I've never run into problems of this nature before, so any insights from
Gnome development veterans would be greatly appreciated!

Michael LeMay

fn:Michael LeMay
org:University of Illinois at Urbana-Champaign;Computer Science
email;internet:lemaymd lemaymd com
title:Ph.D. Student

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]