** ERROR **: Process.vala:232: Should never reach here

Bug #388556 reported by David Ronis
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
AllTray
Fix Released
Low
Unassigned

Bug Description

I'm using alltray 0.7.3 to try and launch an old X application I wrote (it uses Xt). When I start it (alltray MyApp) one of two things happen: 1. It runs, but doesn't show up in the notification area; 2. It cores with the error in the summary on the console. gdb gives the following backtrace:

Core was generated by `alltray XVoiceFax'.
Program terminated with signal 5, Trace/breakpoint trap.
[New process 4930]
#0 IA__g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR,
    format=0x805e008 "Process.vala:232: Should never reach here.",
    args1=0xbf90295c "N·Ì·¼²Ô·\b\\\b\b0;\v\b\001") at gmessages.c:512
512 g_private_set (g_log_depth, GUINT_TO_POINTER (depth));
(gdb) thread apply all bt full

Thread 1 (process 4930):
#0 IA__g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR,
    format=0x805e008 "Process.vala:232: Should never reach here.",
    args1=0xbf90295c "N·Ì·¼²Ô·\b\\\b\b0;\v\b\001") at gmessages.c:512
 depth = 0
 domain = <value optimized out>
 data = (gpointer) 0x0
 log_func = (GLogFunc) 0xb7cab5f0 <IA__g_log_default_handler>
 domain_fatal_mask = 5
 test_level = G_LOG_FLAG_FATAL
 was_recursion = 0
 i = <value optimized out>
#1 0xb7cabff6 in IA__g_log (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR,
    format=0x805e008 "Process.vala:232: Should never reach here.")
    at gmessages.c:526
No locals.
#2 0x08052254 in _all_tray_process_die_if_not_unset_gsource_func (
    self=0x8062af0) at Process.c:476
No locals.
#3 0xb7ca29ac in g_timeout_dispatch (source=0x808c950, callback=0,
    user_data=0x8062af0) at gmain.c:3250
No locals.
---Type <return> to continue, or q <return> to quit---
#4 0xb7ca2288 in IA__g_main_context_dispatch (context=0x8085c08)
    at gmain.c:1814
No locals.
#5 0xb7ca5898 in g_main_context_iterate (context=0x8085c08,
    block=<value optimized out>, dispatch=1, self=0x808a7c0) at gmain.c:2445
 max_priority = 2147483647
 timeout = 2165
 some_ready = 1
 nfds = <value optimized out>
 allocated_nfds = <value optimized out>
 fds = <value optimized out>
 __PRETTY_FUNCTION__ = "g_main_context_iterate"
#6 0xb7ca5d1f in IA__g_main_loop_run (loop=0x808afc0) at gmain.c:2653
 self = (GThread *) 0x808a7c0
 __PRETTY_FUNCTION__ = "IA__g_main_loop_run"
#7 0xb78e3439 in IA__gtk_main () at gtkmain.c:1205
 tmp_list = (GList *) 0xbf902bbc
 functions = (GList *) 0x0
 init = (GtkInitFunction *) 0x0
 loop = (GMainLoop *) 0x808afc0
#8 0x0804d72b in all_tray_program_run (self=0x8066618) at AllTray.c:522
 _inner_error_ = (GError *) 0x0
 _tmp2_ = (WnckScreen *) 0xbf902bbc
---Type <return> to continue, or q <return> to quit---
 _tmp1_ = <value optimized out>
 __PRETTY_FUNCTION__ = "all_tray_program_run"
#9 0x0804e09b in all_tray_program_main (args=0xbf902c94, args_length1=2)
    at AllTray.c:775
 atray = <value optimized out>
 _tmp1_ = (AllTrayProgram *) 0x8066618
 _tmp2_ = <value optimized out>
#10 0x0804e0e0 in main (argc=2, argv=0xbf902c94) at AllTray.c:781

I'm on a 686 slackware 12.2 box running a current version of gnome (2.27.3) and use gcc 4.4.0 to compile.

Revision history for this message
Michael B. Trausch (mtrausch) wrote :

It looks to me like the XVoiceFax application needs to be updated. The error message from Process.vala that is being shown happens after AllTray attempts to find an application the normal way, that fails, and then it tries really hard to find a window that matches the spawned process.

This requires that the target application (either directly, or through use of its toolkit) comply with current standards (namely, the ICCCM and the EWMH). Partial compliance may also work; try just setting _NET_WM_PID on the windows that the application generates to see if that fixes it (at least with AllTray).

I'll fix AllTray to better report this error condition. Thanks for the report!

Changed in alltray:
importance: Undecided → Low
milestone: none → 0.7.4dev
status: New → Confirmed
Revision history for this message
Michael B. Trausch (mtrausch) wrote :

Just to confirm that, by the way, can you run 'wnckprop' on a terminal (with your application running) and then click on the application window for the app that you're trying to dock?

Also, does your app fork and then go to the background? Because that code in AllTray should only be triggered when AllTray's child has died and AllTray expects to find the application in the window system within its process group.

That is another possibility, too, though: Does the application put itself into a new process group? If so, and it forks itself to background itself, there's nothing that can be done. AllTray can deal with children forking and dying by using the process group to determine what application is supposed to actually be attached, but if the application also changes PGIDs, then there is nothing else that can be done.

Revision history for this message
Michael B. Trausch (mtrausch) wrote :

Error message has been clarified in the AllTray sources, fix committed in r114 of lp:alltray

Changed in alltray:
status: Confirmed → Fix Committed
Revision history for this message
David Ronis (david-ronis) wrote :

Couple of things:

1. wnckprop shows:

wnckprop
Xlib: extension "RANDR" missing on display ":0.0".
Name: XVoiceFax: Version 1.5.4
Icon Name: XVoiceFax
Icons: <unset>
On Workspace: 0 ("Workspace 1")
On Screen: 0 (Window Manager: Metacity)
Window Type: normal window
Geometry (x, y, width, height): 1284, 55, 890, 703
Class Group: XVoiceFax
XID: 25165879
PID: <unset>
Session ID: <unset>
State: normal
Possible Actions: move, resize, shade, unshade, maximize horizontally, unmaximize horizontally, maximize vertically, unmaximize vertically, change workspace, pin, unpin, minimize, unminimize, maximize, unmaximize, change fullscreen mode, close, make above, unmake above, make below, unmake below

It's a bit strange the PID doesn't appear to be set. ps shows a PID.

2. The app doesn't fork or change its process group, but does decide whether to mapraise or not (basically it looks for new faxes or voicemails). If it finds them then it mapraises itself, if not, it doesn't.

Revision history for this message
Michael B. Trausch (mtrausch) wrote :

PID is the _NET_WM_PID window property, specified in:

 http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507760

If the process creates a window at all, that is what AllTray will check for and dock. The window must have _NET_WM_PID set to be AllTray's child (or a descendant thereof that is in the same PGID).

If the window goes away entirely (is closed), the icon will disappear, as well, and AllTray will begin looking for the application to reappear if the application is AllTray's direct child (and thus AllTray can tell that it is still running).

Revision history for this message
Michael B. Trausch (mtrausch) wrote :

To further clarify my previous comments:

 * _NET_WM_PID must be set by the application itself (or the library that it uses to work with X11). If you use GTK+, this is handled for you; if you use a very low-level library then you will need to set this property on your windows yourself.
 * AllTray expects windows to stay in existence for it to be useful for AllTray to dock them.

Compliance with the EWMH, combined with not leaving the process group, will ensure that the software will work with AllTray. I'll go ahead and write up some additional documentation on this, as well.

Revision history for this message
David Ronis (david-ronis) wrote :

I've just grepped my /usr/include tree for NET_WM_PID--I've gotten no hits. So, I guess I'm out of luck. This is a bit strange, since my freedesktop and X implementations are pretty recent (I'm running Xorg's 1.6.99.1 whic h I built from git 2 months ago.

Anyhow, thanks for your help.

Revision history for this message
Michael B. Trausch (mtrausch) wrote :
Revision history for this message
Michael B. Trausch (mtrausch) wrote :

_NET_WM_PID isn't a symbol that you'll find in a header. It's a property that must be attached to the X11 window.

To set it for a top-level window, you'll want to call whatever property-setting API is provided by Xt. If Xt doesn't permit setting properties on windows, you'll need to do it with Xlib. This goes something along the lines of:

  Atom wm_pid = XInternAtom("_NET_WM_PID", false);
  Atom prop_type = XInternAtom("CARDINAL", false);

  pid_t my_pid = getpid();
  XChangeProperty(display, target_window, wm_pid, prop_type, 32, PropModeReplace, (unsigned char *)my_pid, 1);

Though I don't routinely write Xlib code, so you may need to do things slightly differently. That's the general gist of it though.

Personally, I would recommend upgrading to an EWMH-specification-aware toolkit, if you can. That will be much easier than trying to implement EWMH functionality on your own.

Revision history for this message
David Ronis (david-ronis) wrote :

I added the code to set _NET_WM_PID; specifically, for the Xt widgets:

 XtRealizeWidget(toplevel);

  {
    Atom wm_pid = XInternAtom(XtDisplay(toplevel), "_NET_WM_PID", False);
    Atom prop_type = XInternAtom(XtDisplay(toplevel), "CARDINAL", False);

    pid_t my_pid = getpid();
    if ((wm_pid == None ) || (prop_type == None))
      fprintf(stderr, "Property not defined\n");
    else
      XChangeProperty(XtDisplay(toplevel), XtWindow(toplevel),
      wm_pid, prop_type,
      32, PropModeReplace,
      (unsigned char *)&my_pid, 1);
  }

Sure enough, xprop or wnckprop now show the PID and alltray sort of works. By that I mean that the icon appears in the notification area and I can click on it to unmap the application; however, it doesn't simply disappear, rather it goes to the wm's list of programs. Worse, clicking on the alltray icon again does nothing.

Revision history for this message
Michael B. Trausch (mtrausch) wrote :

AllTray doesn't perform any mapping/unmapping, just hiding the windows. It works only with window managers that support specs, though there was a bug that affected KDE and OpenBox that was fixed just after the 0.7.3dev release (you could still see the application in the task bar/window list for those systems, and try to alt+tab to it, but now you cannot).

Is this application generally available? Sounds like it may possibly be triggering a bug of some sort or another.

Could you include the output of AllTray with full debugging when you file your bug report for this new issue? Like so:

  $ ALLTRAY_DEBUG=ALL alltray -D progName

That should help give an indication of what is going wrong.

Revision history for this message
David Ronis (david-ronis) wrote :

I ran as you suggested (actually twice) the first didn't generate anything--no alltray icon nor the running program. I killed it off and reran. I get the behavior I described above. [I clicked on the icon in the notification area a few times too].

I'm the author of the program and had released it under GPL. I"ve attached the output log and the source code.

Revision history for this message
David Ronis (david-ronis) wrote :

Seems that you can only add 1 attachment at a time. Here's the source code.

Revision history for this message
David Ronis (david-ronis) wrote :

I'm still having trouble. Alltray still aborts occasionally, often doesn't find the notification area. The latest backtrace is attached.

Revision history for this message
Michael B. Trausch (mtrausch) wrote :

Hrm, which version are you using? Can you send the output of "alltray -V"? Also, can you try using current lp:alltray to see if your problem is fixed? The error message here doesn't exist in the source code any longer, instead it has been replaced with some additional code to handle various situations and aborts with a more descriptive error in the event that we have an application that we really can't work around the quirks of, which was changed in revisions 114 and 119 of lp:alltray – if you're still having trouble after that, please file a new bug report; if you're not able to test with lp:alltray, I am working on getting changes in for the 0.7.4dev release as soon as possible, which can be used for another round of testing.

Revision history for this message
David Ronis (david-ronis) wrote :

alltray -V
Xlib: extension "RANDR" missing on display ":0.0".
AllTray 0.7.3dev
Copyright (c) 2009 Michael B. Trausch <email address hidden>
Licensed under the GNU GPL v3.0 as published by the Free Software Foundation.

Configured Mon Jul 6 21:40:54 UTC 2009 on Linux 2.6.30
Compilers: Not installed and gcc (GCC) 4.4.0
Configure flags: '--prefix=/opt/garnome-svn-2.27' '--exec_prefix=/opt/garnome-svn-2.27' '--bindir=/opt/garnome-svn-2.27/bin' '--sbindir=/opt/garnome-svn-2.27/sbin' '--libexecdir=/opt/garnome-svn-2.27/libexec' '--datadir=/opt/garnome-svn-2.27/share' '--sysconfdir=/opt/garnome-svn-2.27/etc' '--sharedstatedir=/opt/garnome-svn-2.27/share' '--localstatedir=/opt/garnome-svn-2.27/var' '--libdir=/opt/garnome-svn-2.27/lib' '--infodir=/opt/garnome-svn-2.27/info' '--includedir=/opt/garnome-svn-2.27/include' '--mandir=/opt/garnome-svn-2.27/man' '--disable-debug' '--disable-static' '--disable-maintainer-mode' '--with-html-dir=/opt/garnome-svn-2.27/share/gtk-doc/html' '--disable-gtk-doc' '--enable-debug' '--enable-tests' 'CC=/usr/bin/gcc' 'CFLAGS= -I/opt/garnome-svn-2.27/include -L/opt/garnome-svn-2.27/lib -O2 -g -pipe' 'LDFLAGS=-Wl,--export-dynamic -L/opt/garnome-svn-2.27/lib' 'CPPFLAGS=-I/opt/garnome-svn-2.27/include'

I presume lp:alltray refers to git or svn or CVS. Where are the download details?

Revision history for this message
Michael B. Trausch (mtrausch) wrote :

Ahh, yes. lp:alltray renders as a hyperlink on Launchpad, which goes to the AllTray bzr branch:

https://bugs.edge.launchpad.net/+branch/alltray

You can fetch these sources using the bzr revision control system, and the sources are hosted here on Launchpad. The command to do that would be:

 bzr branch lp:alltray

Also, you will need to have autoconf 2.60, automake 1.10, and Vala 0.7.4, in addition to AllTray's dependencies of GLib, GLib-GObject, libgtop, libwnck, and GTK+.

Changed in alltray:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.