On Wed, Dec 04, 2002 at 11:38:44PM -0800, Dorothy Robinson wrote:
> I put the code snippet in and captured some of its output, and caught
> about 4 HandlePropertyNotify calls in gdb. Hope this helps.
>
> - dorothy
>
> Dominik Vogt wrote:
>
> >Interesting. Fvwm should not be in the HandlePropertyNotify()
> >function at all. My guess is that either an innfinite number of
> >PropertyNotify events is generated by the application, or that
> >fvwm receives the same event again and again. Can you please add
> >this code at the front of the HandlePropertyNotify() function in
> >events.c (line 2526), right after the "DBUG" statement:
> >
> >---------------------------- snip ---------------------------
> >fprintf(
> > stderr, "pn: ser 0x%x time 0x%x atom 0x%x w 0x%08x '%s'\n",
> > (int)te->xproperty.serial, (int)te->xproperty.time,
> > (int)te->xproperty.atom, (int)te->xproperty.window,
> > (fw) ? fw->visible_name : "(null)");
> >---------------------------- snip ---------------------------
> >
> >And post a few lines from the end of the output once it is hung?
> >THis should confirm either of my theories. If the numbers "ser"
> >and "time" do not change, it is the same event again and again.
> >
> >In any case, can you repeat the single stepping session until it
> >enters HandlePropertyNotify() for a second time, please? Just
> >hold down the return key in gdb and wait until you have seen the
> >"fprint" from above two times.
>
> pn: ser 0x1d4f time 0x0 ...
> pn: ser 0x1d4f time 0x0 ...
> pn: ser 0x1d4f time 0x0 ...
^^^^^^ ^^^
As I suspected, the same event gets processed again and again.
> (gdb) s
> Single stepping until exit from function _poll,
> which has no line number information.
> 0xfefcd15c in select () from /usr/lib/libc.so.1
...
I'm sorry, but this is still too short to see what is going on.
You probably just looked for "HandlePropertyNotify" in the output.
That string is printed every time a function call inside
HandlePropertyNotify returns. May I ask you to repeat the
procedure? The output should be much longer. I am sorry that I
have to bother you again, but I can not find the root cause of the
problem by looking at the code, and it works fine on my machine.
Apply this patch to events.c:
------------------------------ snip -----------------------------
*** events.c.orig Thu Dec 5 11:08:40 2002
--- events.c Thu Dec 5 11:09:05 2002
***************
*** 2642,2647 ****
--- 2642,2648 ----
break;
case XA_WM_ICON_NAME:
+ fprintf(stderr,"********************** XA_WM_ICON_NAME\n");
flush_property_notify(XA_WM_ICON_NAME, FW_W(fw));
if (HAS_EWMH_WM_ICON_NAME(fw))
{
------------------------------ snip -----------------------------
(Paste it into a file events.patch and the run
"patch < events.patch" in the fvwm/fvwm directory, or just add the
fprintf line without the '+' manually).
Then, after recompiling and reinstalling, trigger a hang and
attach the debugger as usual. Note the line number of the fprintf
statement.
Switch to events.c, set a breakpoint at the fprintf statement and
let fvwm run into it
(gdb) list events.c:1
<ignore output>
(gdb) break <line number of fprintf statement>
(gdb) cont
Fvwm should stop again at the line with the fprintf statement.
Now, single step through the code as before until you come across
the fprintf line again. This should generate at least several
hundred lines of output.
--
When you generated the necessary output, please fetch the latest
CVS code and check wheter the problem persists. I fixed a bug
that is related to the debug output, but I do not think it should
fix the problem. Even if it does, I suspect there must be another
bug.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
