Re: Reproductible crash

2013-04-23 Thread Dominique Michel
Le Tue, 23 Apr 2013 12:57:38 +0100,
Thomas Adam tho...@fvwm.org a écrit :

 On 23 April 2013 12:21, Dominique Michel dominique.mic...@vtxnet.ch
 wrote:
  It is the %i in TitleFormat that caused the crash. With other
  parameters, fvwm doesn't crash. I know, it is no icon defined for
  FvwmStalonePanel. But I don't know if you already know that fvwm can
  crash in such a situation.
 
 I'll be the judge of that.  I can't reproduce this.  I need a
 stacktrace from a corefile, or some other minimal means of reproducing
 your problem.

I don't think you want it. gdb show me:
 
Core was generated by `stalonetray --decorations none --parent-bg true
--window-type dock --no-shrink'. Program terminated with signal 11,
Segmentation fault. #0  0x7f2db920caeb in ?? ()

In fvwm log, it is:
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server
:1 after 5 requests (5 known processed) with 0 events remaining.
XIO:  fatal IO error 2 (No such file or directory) on X server :1
  after 22 requests (22 known processed) with 0 events remaining.

I think this is stalonetray that made fvwm to crash. I will report this
to Roman Dubtsov.

 
 A single style entry of:
 
 Style * !Icon, TitleFormat %i
 
 Does not make FVWM crash.
 
 -- Thomas Adam


-- 
We have the heroes we deserve.



Re: Reproductible crash

2013-04-23 Thread Dominique Michel
Le Tue, 23 Apr 2013 14:16:56 +0100,
Thomas Adam tho...@fvwm.org a écrit :

 On 23 April 2013 14:13, Dominique Michel dominique.mic...@vtxnet.ch
 wrote:
  Le Tue, 23 Apr 2013 12:57:38 +0100,
  Thomas Adam tho...@fvwm.org a écrit :
 
  On 23 April 2013 12:21, Dominique Michel
  dominique.mic...@vtxnet.ch wrote:

 So how is FVWM taken out by this?  FVWM isn't crashing from the
 corefile you're showing here.

The whole backtrace for fvwm is as follow:

Thread 1 (LWP 32646):
#0  0x7f2db920caeb in ?? ()
No symbol table info available.
#1  0x in ?? ()
No symbol table info available

Doing the same for stalonetray show:

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need set solib-search-path or set sysroot?
Core was generated by `stalonetray --decorations none --parent-bg true
--window-type dock --no-shrink'. Program terminated with signal 11,
Segmentation fault. #0  XSync (dpy=0x0, discard=0)
at /var/tmp/portage/x11-libs/libX11-1.5.0-r2/work/libX11-1.5.0/src/Sync.c:42
42  /var/tmp/portage/x11-libs/libX11-1.5.0-r2/work/libX11-1.5.0/src/Sync.c:
Aucun fichier ou dossier de ce type.

Thread 1 (LWP 32646):
#0  XSync (dpy=0x0, discard=0)
at /var/tmp/portage/x11-libs/libX11-1.5.0-r2/work/libX11-1.5.0/src/Sync.c:42
rep = {type = 0 '\000', revertTo = 0 '\000', sequenceNumber = 0, length
= 0, focus = 0, pad1 = 0, pad2 = 0, pad3 = 0, pad4 = 3111012096, pad5 =
32557} #1  0x0040298a in ?? () No symbol table info available.
#2  0x7f2db8c45509 in __run_exit_handlers (status=-1,
listp=0x7f2db8fb45c8 __exit_funcs,
run_list_atexit=run_list_atexit@entry=true) at exit.c:77 atfct =
optimized out onfct = optimized out cxafct = optimized out f =
optimized out #3  0x7f2db8c45595 in __GI_exit (status=optimized
out) at exit.c:99 No locals.
#4  0x00403dec in ?? ()
No symbol table info available.
#5  0x7f2db8c2ec15 in __libc_start_main (main=0x403ce0, argc=17,
ubp_av=0x7fffbde7d918, init=optimized out, fini=optimized out,
rtld_fini=optimized out, stack_end=0x7fffbde7d908) at
libc-start.c:258 result = optimized out unwind_buf = {cancel_jmp_buf
= {{jmp_buf = {0, 754501913821412383, 4204480, 140736379476240, 0, 0,
-754356573086843873, -854567942409978849}, mask_was_saved = 0}}, priv =
{pad = {0x0, 0x0, 0x40cb20, 0x7fffbde7d918}, data = {prev = 0x0,
cleanup = 0x0, canceltype = 4246304}}} not_first_call = optimized out
#6  0x004027e9 in ?? () No symbol table info available. #7
0x7fffbde7d908 in ?? () No symbol table info available. #8
0x in ?? () No symbol table info available.

What look strange to me is Xsync that doesn't find a file at
/var/tmp/portage/x11-libs/libX11-1.5.0-r2/work/libX11-1.5.0/src/Sync.c

/var/tmp/portage/x11-libs/libX11-1.5.0-r2/work/libX11-1.5.0/ is the
location of the source when portage build libX11 before to install it.

So, maybe a gentoo specific bug.


 
 -- Thomas Adam


-- 
We have the heroes we deserve.