On Sun, Sep 15, 2013 at 10:13:29AM -0400, Dan Espen wrote:
D> Gleb Smirnoff <[email protected]> writes:
D>
D> > Configuration Information [Automatically generated, do not change]:
D> > uname: FreeBSD think.nginx.com 10.0-CURRENT FreeBSD 10.0-CURRENT #11
r254323: Wed Aug 14 17:08:51 MSK 2013
[email protected]:/usr/obj/usr/src/head/sys/THINKPAD_X1 amd64
D> > compiler flags: cc -Wall -Wno-implicit-int -g -I/usr/local/include
D> >
D> > FVWM Version: 2.6.5
D> > FVWM_MODULEDIR: /usr/local/libexec/fvwm/2.6.5
D> > FVWM_DATADIR: /usr/local/share/fvwm
D> > FVWM_USERDIR: /home/glebius/.fvwm
D> >
D> > Description:
D> > Fvwm crashes in free() in libc couple of times per day. Crashes
D> > are different, and call path can involve different libraries,
D> > but the problem is always in free().
D> >
D> > Here is an example:
D> >
D> > (gdb) bt
D> > #0 __free (ptr=0x796b6369745321) at arena.h:504
D> > #1 0x0000000800bc02a7 in XFreeStringList (list=0x804a18c08) at
TextToStr.c:113
D> > #2 0x00000000004de0a3 in FlocaleFreeNameProperty (ptext=0x804a05010)
D> > at Flocale.c:2358
D>
D> Sorry, I've tried just setting LC_TYPE to ru_RU.UTF-8.
D> That doesn't seem to be sufficient to cause the problem.
A crash happens one or two times during working day. Not every windows
close causes crash.
D> Any more hint's would be helpful.
D>
D> If you know how to use gdb, a print of ptext might be helpful.
(gdb) p *ptext
$1 = {
name = 0x804a29500 "Шо�\201�\201е�\200 зимой на оживленной
п�\200иго�\200одной �\202�\200а�\201�\201е - С�\202�\200ани�\206а 26 - Mozilla
Firefox", name_list = 0x804a18c08}
(gdb) p *ptext->name_list
$2 = 0x796b6369745321 <Address 0x796b6369745321 out of bounds>
(gdb)
Another crash:
(gdb) p *ptext
$1 = {
name = 0x804a2a480 "«�\227де�\201�\214 должн�\213 б�\213ли
по�\201�\202�\200ои�\202�\214 новое об�\211ежи�\202ие �\234�\223У» - Public
forum of MSU united student networks - Mozilla Firefox",
name_list = 0x804a18a50}
(gdb) p *ptext->name_list
$2 = 0x163 <Address 0x163 out of bounds>
It looks like the memory garbaging happens earlier than we encounter assertion,
and actually the trace from core isn't a place where error lives.
Here I have a crash with different trace. Now assertion is hit in malloc(),
not free().
(gdb) bt
#0 arena_run_reg_alloc (run=0x804827000, bin_info=0x803134d90) at bitmap.h:99
#1 0x0000000802e3d081 in __jemalloc_arena_malloc_small (arena=0x8044000c0,
size=96, zero=false)
at /usr/obj/usr/src/head/lib/libc/jemalloc_arena.c:1435
#2 0x0000000802e4434f in __malloc (size=Cannot access memory at address 0x1
) at arena.h:918
#3 0x000000000050b888 in safemalloc (length=88) at safemalloc.c:43
#4 0x00000000004c1451 in make_named_packet (len=0x7fffffffd1ec,
event_type=2048, name=0x804a3d6e0 "Facebook - Mozilla Firefox", num=3)
at module_interface.c:407
#5 0x00000000004c1567 in BroadcastName (event_type=2048, data1=33554549,
data2=4195027, data3=34437353472,
name=0x804a3d6e0 "Facebook - Mozilla Firefox") at module_interface.c:455
#6 0x00000000004c166c in BroadcastWindowIconNames (fw=0x804a05000, window=0,
icon=1) at module_interface.c:479
#7 0x00000000004d4085 in EWMH_WMIconName (fw=0x804a05000, ev=0x73cb28,
style=0x0, any=0) at ewmh_names.c:190
#8 0x00000000004abd6f in EWMH_ProcessPropertyNotify (exc=0x80482b300)
at ewmh_events.c:1620
#9 0x00000000004468ea in HandlePropertyNotify (ea=0x7fffffffd488)
at events.c:3628
#10 0x000000000044777f in dispatch_event (e=0x7fffffffd4c0) at events.c:4135
#11 0x00000000004481a1 in HandleEvents () at events.c:4179
#12 0x0000000000477293 in main (argc=2, argv=0x7fffffffdbf0) at fvwm.c:2591
(gdb) fr 3
#3 0x000000000050b888 in safemalloc (length=88) at safemalloc.c:43
43 ptr = malloc(length);
(gdb) p length
$1 = 88
(gdb)
--
Totus tuus, Glebius.
