Crash on show icons

[GoogleCodeExporter]

If a try to show icon from preferences menu, the applet crash.
Gnome-2.20.2

Original issue reported on code.google.com by gohan...@gmail.com on 6 Jan 2008 at 11:52

[GoogleCodeExporter]

I'll need more information than this to address this bug. Could you please 
provide
the following:
- Distribution
- The icon you were tying to add (attach it please)
- A crash report if available.

thanks

Original comment by bertol...@gmail.com on 6 Jan 2008 at 5:40

[GoogleCodeExporter]

I can reproduce this on Ubuntu Intrepid (current dev version). This occurs when
simply checking the box in the preference dialog. I have no issues on Hardy. 

Attached you will find a full crash report. Please let me know if there is any
additional information that I can provide.

Original comment by A.Star...@gmail.com on 19 Aug 2008 at 6:49

Attachments:

• _usr_lib_gnome-panel_file-browser-applet.1000.crash

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Reported in Ubuntu:

https://bugs.edge.launchpad.net/ubuntu/+source/file-browser-applet/+bug/259292

Original comment by A.Star...@gmail.com on 29 Aug 2008 at 7:58

[GoogleCodeExporter]

Stacktrace.txt (retraced):

http://launchpadlibrarian.net/16921591/Stacktrace.txt

ThreadStacktrace.txt (retraced):

http://launchpadlibrarian.net/16921593/ThreadStacktrace.txt

Original comment by A.Star...@gmail.com on 29 Aug 2008 at 8:00

[GoogleCodeExporter]

Hi Andrew,

Does the crash happen with the default icon, or was the icon to display 
changed? I
can't reproduce it here :-(

Also, Could you try the newest version (0.5.8) too please?

BTW, thanks for getting the applet unto Ubuntu and Debian.

Original comment by bertol...@gmail.com on 29 Aug 2008 at 8:56

[GoogleCodeExporter]

Well, if the stack trace is to be believed, then WTH!

It looks like the signal_data structure passed to
panel_menu_bar_on_preferences_changed is pointing where it ought not to. The 
stack
trace says

panel_menu_bar_on_preferences_changed(a_prefs=0x9c7f2a0,signal_data=0x0,data=0x9
c89000)

The structure is allocated in applet_preferences_on_show_icon_pressed (via 
g_new0)
and then passed to panel_menu_bar_on_preferences_changed by calling 
g_signal_emit
with signal_data as a parameter. 

So, either g_new0() is returning garbage (not likely) or g_signal_emit is 
loosing the
address somehow?

Ideas anyone?

Original comment by bertol...@gmail.com on 29 Aug 2008 at 9:40

[GoogleCodeExporter]

It persists with 0.5.8, but again it is only on Intrepid not Hardy. I'm 
inclined to
think that there must be some significance in that, but I'm not sure what it 
is...  

Hmm... On second look, I just noticed a difference in the build logs for 
Intrepid and
Hardy (also Sid btw):

...

/usr/bin/make
make[1]: Entering directory `/tmp/buildd/file-browser-applet-0.5.8'
make[2]: Entering directory `/tmp/buildd/file-browser-applet-0.5.8'
make[3]: Entering directory `/tmp/buildd/file-browser-applet-0.5.8'
Scanning dependencies of target file-browser-applet
make[3]: Leaving directory `/tmp/buildd/file-browser-applet-0.5.8'
make[3]: Entering directory `/tmp/buildd/file-browser-applet-0.5.8'
[ 14%] Building C object src/CMakeFiles/file-browser-applet.dir/main.o
[ 28%] Building C object src/CMakeFiles/file-browser-applet.dir/panel-menu-bar.o
[ 42%] Building C object src/CMakeFiles/file-browser-applet.dir/menu-browser.o
[ 57%] Building C object src/CMakeFiles/file-browser-applet.dir/utils.o
/tmp/buildd/file-browser-applet-0.5.8/src/utils.c: In function 
'utils_show_dialog':
/tmp/buildd/file-browser-applet-0.5.8/src/utils.c:56: warning: format not a 
string
literal and no format arguments
[ 71%] Building C object src/CMakeFiles/file-browser-applet.dir/preferences.o
[ 85%] Building C object src/CMakeFiles/file-browser-applet.dir/context-menu.o
[100%] Building C object src/CMakeFiles/file-browser-applet.dir/vfs.o
Linking C executable file-browser-applet
make[3]: Leaving directory `/tmp/buildd/file-browser-applet-0.5.8'
[100%] Built target file-browser-applet

...

That warning with utils.c only appears on Intrepid....

A thought:

Intrepid uses gtk 2.13.7 
Hardy uses gtk 2.12.9
Sid uses gtk 2.12.11

Maybe something changed with gtk? I'm not sure what else Sid and Hardy have 
more in
common than Intrepid. Generally versions of packages are going to be closer in
Intrepid and Sid...

Is Sid using GCC-4.2 by default? I'm not sure. Hardy is still on 4.2, while 
Intrepid
made the bump up to 4.3

Original comment by A.Star...@gmail.com on 29 Aug 2008 at 11:03

[GoogleCodeExporter]

OK, I'm going to have to bite the bullet and upgrade to Intrepid to sort this 
out.

Original comment by bertol...@gmail.com on 31 Aug 2008 at 1:16

[GoogleCodeExporter]

Arg! I have upgraded to Intrepid but still cannot reproduce this bug. I 
definitely
have 2.13.7 installed...

Original comment by bertol...@gmail.com on 3 Sep 2008 at 4:10

[GoogleCodeExporter]

I can no longer reproduce this on Intrepid. Both the version in the archive and 
a new
build of 0.5.9 behave correctly now. I wish I knew what the exact issue was, 
but I
guess we'll just have to chalk it up to Intrepid being under development. There 
must
have been a problem with a dependent package.

Original comment by A.Star...@gmail.com on 10 Sep 2008 at 11:07

[GoogleCodeExporter]

Hey Andrew,

I was going to contact you about possibly debugging this for me some more, but I
guess it's not necessary anymore. I have not been able to reproduce the crash 
at all,
and the trace suggest to me that some data was being lost/corrupted somewhere 
between
g_signal_emit and calling of the callback function.

Anyway, good that fixed itself. Those are the best kind of bugs :-)

Shall we close it?

a.

Original comment by bertol...@gmail.com on 10 Sep 2008 at 11:52

[GoogleCodeExporter]

Closing this issue on 0.6.0 release.

Original comment by bertol...@gmail.com on 3 Nov 2008 at 9:48

• Changed state: Fixed