AWN fails to start on FreeBSD (libwnck)

It would be great if you could build glib/gtk+/libwnck/awn with debug flags and glib/gtk+ with the configure flag "--enable-debug=yes", then run awn under gdb. Slightly more detailed instructions are here: http://wiki.awn-project.org/index.php?title=SubmittingBugReports

When you get it to crash, please copy/paste the resulting backtrace here.

Thanks for your bug report!

Hi there!

I am not Meethune, but I have the same problem, even with up-to-date libwnck and so on. Since I do all my compiles with -g, here comes two backtraces:

1. The one leading to the assertion:

#0 set_icon (class_group=0x29211718) at class-group.c:414
 icon = (GdkPixbuf *) 0x280cc29b
 mini_icon = (GdkPixbuf *) 0x0
 __PRETTY_FUNCTION__ = "set_icon"
#1 0x280d4304 in do_update_now (screen=0x29231e48) at screen.c:1615
No locals.
#2 0x280d4988 in update_idle (data=0x29231e48) at screen.c:2338
No locals.
#3 0x28e2ae71 in g_idle_dispatch (source=0x296d64c0,
    callback=0x280d4970 <update_idle>, user_data=0x29231e48) at gmain.c:4132
No locals.
#4 0x28e2ca35 in IA__g_main_context_dispatch (context=0x29240b70)
    at gmain.c:2061
No locals.
#5 0x28e2fdd2 in g_main_context_iterate (context=0x29240b70, block=1,
    dispatch=1, self=0x29205040) at gmain.c:2694
 got_ownership = Variable "got_ownership" is not available.
#6 0x28e30177 in IA__g_main_loop_run (loop=0x293a4d40) at gmain.c:2898
#7 0x28797243 in IA__gtk_main () at gtkmain.c:1163
#8 0x08051715 in main (argc=1, argv=0xbfbfe814) at main.c:278

The following coredump adds this on top of the latter:

#0 0x291cddb7 in kill () from /lib/libc.so.7
#1 0x290f31c7 in raise () from /lib/libthr.so.3
#2 0x291cc92a in abort () from /lib/libc.so.7
#3 0x28e356f9 in IA__g_logv (log_domain=Variable "log_domain" is not available.
) at gmessages.c:497
 buffer = "([è\025)\230\027\036)ðÆo)Ø\0337)xà¿¿\236ë\025)\200Åo)ÐÆo)Ðvp)\000Ço)¦\002\000\0000K\017)\000\000\000\000}\206á(\030Ôé(ðÆo)\230à¿¿ÞB\017)ðÆo)\000\000\000\000ÐÆo)ÞB\017)\000\000\000\000\000\021 )Xá¿¿KÀÝ(\000\000\000\000\000\021 )\204\000\000\000DK\017)àÆo)¸§ß(©&\017)t\002^(\000\016o)\020\000\000\000Øà¿¿Åß](\001\000\000\000\030Ôé(©&\017)t\002^(PP\017)\b\000\000\000øà¿¿ÞB\017)\001\000\000\000\030Ôé(há¿¿\002\217ä"...
 depth = 1
 domain = (GLogDomain *) 0x0
 data = 0x0
 log_func = 0x28e36010 <IA__g_log_default_handler>
 domain_fatal_mask = 5
 test_level = Variable "test_level" is not available.
#4 0x28e35739 in IA__g_log (log_domain=0x280ee365 "Wnck",
    log_level=G_LOG_LEVEL_ERROR,
    format=0x28e65fe0 "file %s: line %d (%s): assertion failed: (%s)")
    at gmessages.c:517
#5 0x28e357b8 in IA__g_assert_warning (log_domain=0x280ee365 "Wnck",
    file=0x280ee83a "class-group.c", line=430,
    pretty_function=0x280eea09 "set_icon",
    expression=0x280ee848 "icon && mini_icon") at gmessages.c:552

This is with current bzr-checkout and libwnck 2.20.3
Can I provide more useful information? Just tell me what else I can do to help, because I really *love* awn on Linux :o)

My suspicion is that following:

libwnck is failing on a call to gdk_pixbuf_scale_simple() in the function default_icon_at_size() in libwnck/xutils.c in the libwnck source.

If you're comfortable editing source etc... I'd be interested to see what happens if you placed a

g_assert(scaled);

immediately following the call to gdk_pixbuf_scale_simple() in that function.

It doesn't kick in, because both GdkPixbuf **iconp and GdkPixbuf **mini_iconp are set to NULL during the call of get_icons_from_windows().
Hm... I get the suspicion that set_icon() should make sure it never calls _wnck_get_fallback_icons() with icon and mini_icon set to NULL....
What else can I do to help?

Hello,

Any news about this bug? Have exactly the same problem with AWN.

#uname -rsm
FreeBSD 6.3-RELEASE i386

avant-window-navigator-0.2.1

"Any news about this bug? Have exactly the same problem with AWN."

No news. No awn devs that I'm aware of have freebsd systems available. Honestly makes it very difficult to debug. I'll try and look at the code, in the next couple days, and compare it to what Mark Daniel Reidel says above and see if it gives me any ideas. But, like I say it's difficult.

If anyone knows of a qemu or vmware freebsd image out there that can support composite (even if it is brutally slow... and I don't know if it is possible) I'd be willing to load it up and try to work things out as long as I didn't have to do any configuration or major installations:-).... I suspect that something like xcompmgr or cairo compmgr might work??

Good (or bad?) news, everyone...

I finally found what seems to be the problem of it all. libawn redefines _wnck_get_fallback_icons() as an empty function in src/xutils.c, not doing anything. If I delete that part and also comment out the "if (iconp)" and "if (mini_iconp)" in the xutils.c of libwnck, it sort of works for me.
Is these any specific reason to replace that function with a dummy? And why is this FreeBSD-specific???

"Good (or bad?) news, everyone..."

Thanks for tracking that down :-) I'm going to go and remove that and see what happens.

I've actually been meaning to ask njpatel (lead dev) why src/xutils.c is even in there....

I'm running with _wnck_get_fallback_icons() removed from awn's src/xutils.c and not seeing any issue. I'll run it this way for a bit. My guess is that this file's presence is probably a artifact of the existing version of libwnck having issues at the time awn was originally released.

I'm going to look into removing the file completely.

njpatel: Any thoughts on this?

hmmm... removing the files completely doesn't look trivial.

I think I'll just wait a bit and see if I can find out the purpose/need for it.

Could someone try one of the following patches. The first one is against awn-core-testing. And the second is against trunk (their Makefile.am s are a bit different)

This patch is against awn-core-testing.

This patch is against awn trunk.

There is an issue with patch against trunk. I will upload a revised one shortly.

Patch has been committed to awn-extras-testing for further testing.

Revised patch for awn trunk. I have only done a build test as I have testing installed.

Please note that this patch does cause a regression. Icon resolution is significantly reduce for the core taskmanager/launcher. That can be dealt with once it is determined if this resolves the freebsd crash.

I can confirm that the patch against trunk works indeed very well and also removes the need to patch libwnck, it just works out-of-the-box.
What I still don't understand is why the whole issue seems to be FreeBSD-specific as there also must be cases where under Linux there are applications without any icons.
Do you want me to do any more testing with other releases?

"I can confirm that the patch against trunk works indeed very well and also removes the need to patch libwnck, it just works out-of-the-box."

Great. So the patches will be here for freebsd for now. I'm going to revert the change from testing until the icon degradation issue can be resolved.

"What I still don't understand is why the whole issue seems to be FreeBSD-specific as there also must be cases where under Linux there are applications without any icons."

Some things are best not thought about...

"Do you want me to do any more testing with other releases?"

No need at this point. If you can stay subscribed an additional patch will show up which attempts to fix this issue and the icon degradation issue at the same time. Basically the reason for the xutils.c was mostly because the default size of icon that libwnck uses is too small for a lot of awn bar configs.

Aaah, now I get what you mean with „degradation“. I noticed that icons provided by applications seem to be scaled up and look quite blurry/ugly. I'm informed of any new postings, so as soon as you have any new patches, I'd be happy to test them again.
Thank you very much for the help :o)

Could someone try the attached patch.

I'm just trying to track down the exact trigger of the patch. Even if it does work i may not be perfectly correct.

Thanks.

Hm... the patch doesn't apply at all to revision 164. Is it possible that this patch is against the testing-version?

"Hm... the patch doesn't apply at all to revision 164. Is it possible that this patch is against the testing-version?"

Mark,

We're currently at revision 200. And it is definitely against trunk.

Was this a fresh branch? Might the copy you have already had a previous patch applied? I've just applied it cleanly against revision 200 of trunk. And I'm fairly confident no changes have taken place in the relevant source files between 164 and 200.

My suggestion.

bzr pull

bzr revision info

if it doesn't show revision 200

do a

bzr update

you should have revision 200 at this point regardless.

do a

bzr revert

then apply the patch

Oh damn, I'm so sorry. I assumed that "bzr update" does the same as "cvs update". I did a clean checkout and got version revision 200. The patch applies cleanly ans the results are very promising. The images are no more distorted, when they are smaller, they are no longer upscaled. It's really fancy, thank you very much :o)
What can I test for you to prove that everything works?
I'm really happy things seem to work perfectly :o)))

Mark,

Good to hear. At this point I'm perfectly happy with your tests:-)

Though I may put up a different revision of the patch sometime in the next few days.

Basically, even though the patch is about 80K., the real changes are the removal of about 6 lines us suspect code which I replaced with a call the systems wnck_window_get_icon() function. I'll probably try and find a few Linux guinea pigs to determine if the are any regressions and have njpatel take a look over the affected code when he has an opportunity.

Overall, I'm optimistic we'll see awn building on Freebsd out of the box sometime soon. And a nice side effect is several kilobytes of unused code have been removed from the source :-)

I've pushed a fix into trunk (rev 235, 236). The changes were as minimal as possibly while hopefully avoiding any visual regressions and still accomplishing their goal.