|Summary:||Launching the "Run" dialog crashes the panel|
|Product:||[Fedora] Fedora||Reporter:||Chris Lee <clee>|
|Component:||gnome-panel||Assignee:||Mark McLoughlin <markmc>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||gnome-panel-2.8.1-4||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-11-01 17:59:08 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Chris Lee 2004-10-23 00:22:54 UTC
User-Agent: Build Identifier: Using the default panel layout in the latest Rawhide snapshot, I navigate to the 'Actions' menu item in the menu bar on the top panel and select "Run Application..." from the menu. The "Run Application" window pops up, and along with it I get an error dialog notifying me that gnome-panel has crashed. Reproducible: Always Steps to Reproduce: 1. Log into GNOME. 2. Click on the 'Actions' menu 3. Select 'Run Applications...' Actual Results: The panel crashes. Expected Results: ....
Comment 1 Chris Lee 2004-10-23 00:24:04 UTC
Updating severity to note that this is in fact a crasher.
Comment 2 Chris Lee 2004-10-23 00:24:41 UTC
Oh, also - please note that this bug does seem to be IA64-specific.
Comment 3 Chris Lee 2004-10-25 18:07:19 UTC
Adding this to the GNOME-breaks-on-ia64 blocker list
Comment 4 Dave Malcolm 2004-10-26 19:30:09 UTC
I'm having a look at this since I believe markmc is on vacation right now.
Comment 5 Dave Malcolm 2004-10-26 20:28:41 UTC
Seems to be dying inside 3rd invocation of get_all_applications within panel_run_dialog_add_items_idle, with a corrupt GSList of all_applications (using GSList code from /usr/lib/libglib-2.0.so.0) (gdb) print all_applications $28 = (GSList *) 0x60000000002ffe68 (gdb) print all_applications->next $29 = (GSList *) 0x60000000003011c0 (gdb) print all_applications->next->next $30 = (GSList *) 0x6000000000301cd0 (gdb) print all_applications->next->next->next $31 = (GSList *) 0x63412f3a736e6f69 The "data" field in each node is NULL, until: (gdb) print all_applications->next->next->data $35 = 0x746163696c707061 Am investigating further... some kind of 32-bit vs 64-bit borkage?
Comment 6 Dave Malcolm 2004-10-26 21:00:37 UTC
Stupid get_all_applications function supposedly returns a GSList*, but never actually has a "return" statement. Looks like it's managing to work on every other architecture, but ia64 is fussy about such things. I'll try to patch things...
Comment 7 Dave Malcolm 2004-10-27 00:19:52 UTC
I had a look for this in CVS, it turns out get_all_applications is actually supplied by one of our patches, rather than upstream (use-correct-applications.patch); am experimenting with an updated version of the patch that has a fix.
Comment 8 Mark McLoughlin 2004-10-27 17:37:10 UTC
Should just be a "return all_applications;" at the end of the function. I've no idea how that ever worked.
Comment 9 Dave Malcolm 2004-10-27 21:54:24 UTC
OK - after much pain learning the mysteries of multiarch-RPM I've got a patch to the patch that I've verified fixes things on an actual ia64 box. markmc - where do you want me to apply this: FC-3, RHEL-4, devel?
Comment 10 Dave Malcolm 2004-10-27 21:55:30 UTC
Created attachment 105875 [details] Patch to add the return statement to the patch, and to update spec file accordingly
Comment 11 Mark McLoughlin 2004-10-28 09:12:33 UTC
You're probably more aware of what's appropriate than I am - but I'm guessing FC-3, RHEL-4 and devel would all by appropriate. If you're swamped, feel free to bounce this back at me. Thanks Dave ...
Comment 12 Dave Malcolm 2004-10-29 14:53:48 UTC
markmc, can you see this gets done please? Reassigning, thanks.
Comment 13 Mark McLoughlin 2004-11-01 17:59:08 UTC
Fixed and built for rawhide and RHEL4, fix will be in next FC-3 update.