[9fans] drawterm segfault

[9fans] drawterm segfault

[johnny]

Hi!
I've had a strange segfault with drawterm lately. This is with the latest binaries from swtch.com/drawterm.
I have both tried it on sunos and linux, and have the same segfault happen.
The segfault occurs when I'm using acme. I open 3 new windows, and boom, drawterm vanishes. The reammy strange part in it is that it only happens when I open three specific windows in a specific order.
1, start drawterm, using my auth+cpu+fs server at home
2, open an acme window in $home
2, enter directories src/johnny with right-click with mouse, then open file wc.c with right-click, at this point my drawterm window disappears and all I see in the terminal I started drawterm from is: Segmentation fault.
This strangely doesn't happen when I open any other directories, only if i open these in the specified order, when acme starts.
Cheers!
Johnny

Re: [9fans] drawterm segfault

[johnny]

sorry for my ignorance, but how do I compile drawterm with debug symbols?
Thank you for the help.

Re: [9fans] drawterm segfault

[Skip Tavakkolian]

> sorry for my ignorance, but how do I compile drawterm with debug symbols?
> Thank you for the help.

Make.unix shows that -g is already supplied to gcc for linux. what
does gdb show for backtrace?

Re: [9fans] drawterm segfault

[andrey mirtchovski]

does it happen when you open this specific file, or any other file
from src/johnny? if it's only wc.c that kills it, does it kill it when
you open the file directly (acme wc.c)? if it's wc.c, then is there
something special that you have in that file, special french
characters, perhaps? can we see wc.c?

does it happen when you start acme with a single column (acme -c1)?

i just tried with /sys/src/cmd/wc.c copied in $home/src/johnny and it
doesn't crash for me under X11 and OSX, but that doesn't mean much :)

Re: [9fans] drawterm segfault

[johnny]

Continuing.
[New Thread -1250161776 (LWP 9379)]
[New Thread -1261585520 (LWP 9380)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1261585520 (LWP 9380)]
0x08086210 in ?? ()
(gdb) bt
#0  0x08086210 in ?? ()
#1  0x00000000 in ?? ()

===== end gdb output =====

I hope this helps. Thanks.

Re: [9fans] drawterm segfault

[cinap_lenrek]

[-- Attachment #1: Type: text/plain, Size: 163 bytes --]

could you make a stacktrace with gdb please? 

% gdb drawterm drawterm.core
(gdb) bt
...

drawterm should have been compiled with  debug
symbols.

cinap

[-- Attachment #2: Type: message/rfc822, Size: 3272 bytes --]

From: johnny@sorosj.hd.free.fr
To: 9fans@cse.psu.edu
Subject: [9fans] drawterm segfault
Date: Sat, 13 Oct 2007 12:55:56 +0200
Message-ID: <fd3a28dfcfcdd87d6be73877a399b650@sorosj.hd.free.fr>

Hi!
I've had a strange segfault with drawterm lately. This is with the latest binaries from swtch.com/drawterm.
I have both tried it on sunos and linux, and have the same segfault happen.
The segfault occurs when I'm using acme. I open 3 new windows, and boom, drawterm vanishes. The reammy strange part in it is that it only happens when I open three specific windows in a specific order.
1, start drawterm, using my auth+cpu+fs server at home
2, open an acme window in $home
2, enter directories src/johnny with right-click with mouse, then open file wc.c with right-click, at this point my drawterm window disappears and all I see in the terminal I started drawterm from is: Segmentation fault.
This strangely doesn't happen when I open any other directories, only if i open these in the specified order, when acme starts.
Cheers!
Johnny

Re: [9fans] drawterm segfault

[erik quanstrom]

> Continuing.
> [New Thread -1250161776 (LWP 9379)]
> [New Thread -1261585520 (LWP 9380)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1261585520 (LWP 9380)]
> 0x08086210 in ?? ()
> (gdb) bt
> #0  0x08086210 in ?? ()
> #1  0x00000000 in ?? ()

you may be debugging the wrong thread.  it's been a while
since i've fired up gdb, but i think the command is "thread."
you'll need to do a backtrace in each thread.  alternatively,
if you have a core file, p9p core may give better output.

- erik

Re: [9fans] drawterm segfault

[cinap_lenrek]

[-- Attachment #1: Type: text/plain, Size: 74 bytes --]

passing -g option to gcc? edit makefile or CFLAGS="-g" i guess.

cinap

[-- Attachment #2: Type: message/rfc822, Size: 2582 bytes --]

From: johnny@sorosj.hd.free.fr
To: 9fans@cse.psu.edu
Subject: Re: [9fans] drawterm segfault
Date: Sat, 13 Oct 2007 19:40:57 +0200
Message-ID: <b3d2a817de4234e5a8cb2cfc0d86796a@sorosj.hd.free.fr>

sorry for my ignorance, but how do I compile drawterm with debug symbols?
Thank you for the help.

Re: [9fans] drawterm segfault

[johnny]

you were right, that was just one thread.
Now I used thread apply all bt command to get the backtrace.
Here is what I got:

===== Begin gdb output =====
$ gdb
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
(gdb) attach 13176
Attaching to process 13176
Reading symbols from /usr/bin/drawterm...(no debugging symbols found)...done.
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Reading symbols from /usr/lib/libX11.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libX11.so.6
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
[New Thread -1210783072 (LWP 13176)]
[New Thread -1250116720 (LWP 13183)]
[New Thread -1241724016 (LWP 13182)]
[New Thread -1233331312 (LWP 13179)]
[New Thread -1224938608 (LWP 13178)]
[New Thread -1216283760 (LWP 13177)]
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /usr/lib/libXau.so.6...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXau.so.6
Reading symbols from /usr/lib/libXdmcp.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXdmcp.so.6
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/tls/i686/cmov/libnss_compat.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_compat.so.2
Reading symbols from /lib/tls/i686/cmov/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libnsl.so.1
Reading symbols from /lib/tls/i686/cmov/libnss_nis.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_nis.so.2
Reading symbols from /lib/tls/i686/cmov/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_files.so.2
Reading symbols from /usr/lib/libXcursor.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXcursor.so.1
Reading symbols from /usr/lib/libXrender.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXrender.so.1
Reading symbols from /usr/lib/libXfixes.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXfixes.so.3
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1224938608 (LWP 13178)]
0x08086210 in ?? ()
(gdb) thread apply all bt

Thread 6 (Thread -1216283760 (LWP 13177)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7e24647 in poll () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7efb839 in ?? () from /usr/lib/libX11.so.6
#3  0x080e1178 in ?? ()
#4  0x00000001 in ?? ()
#5  0xffffffff in ?? ()
#6  0xb7fabb2c in ?? () from /usr/lib/libX11.so.6
#7  0x080e0b60 in ?? ()
#8  0xb7fabb2c in ?? () from /usr/lib/libX11.so.6
#9  0x080e0b60 in ?? ()
#10 0x00000000 in ?? ()

Thread 5 (Thread -1224938608 (LWP 13178)):
#0  0x08086210 in ?? ()
#1  0x00000000 in ?? ()

Thread 4 (Thread -1233331312 (LWP 13179)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7eaf676 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x0805d8fc in ?? ()
#3  0x08107420 in ?? ()
#4  0x08107408 in ?? ()
#5  0xb67ccd48 in ?? ()
#6  0x081065dc in ?? ()
#7  0x00000000 in ?? ()

Thread 3 (Thread -1241724016 (LWP 13182)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7eaf676 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x0805d8fc in ?? ()
#3  0x0810e8f0 in ?? ()
#4  0x0810e8d8 in ?? ()
#5  0xb5fcbce8 in ?? ()
#6  0x080d2ec4 in ?? ()
#7  0x080d2e80 in ?? ()
---Type <return> to continue, or q <return> to quit---
#8  0x0805b710 in ?? ()
#9  0xb5fcbd18 in ?? ()
#10 0x08058f10 in ?? ()
#11 0x080d2ec4 in ?? ()
#12 0x00002e60 in ?? ()
#13 0xb5fcbd08 in ?? ()
#14 0x0808de51 in ?? ()
#15 0x080d2e80 in ?? ()
#16 0x00000014 in ?? ()
#17 0x00000000 in ?? ()

Thread 2 (Thread -1250116720 (LWP 13183)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7eaf676 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x0805d8fc in ?? ()
#3  0x08111f88 in ?? ()
#4  0x08111f70 in ?? ()
#5  0xb57cae28 in ?? ()
#6  0x080bcf58 in ?? ()
#7  0x00000000 in ?? ()

Thread 1 (Thread -1210783072 (LWP 13176)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7eb2518 in recv () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x08054666 in ?? ()
#3  0x00000007 in ?? ()
#4  0x08116720 in ?? ()
#5  0x00010000 in ?? ()
#6  0x00000000 in ?? ()
#0  0x08086210 in ?? ()
(gdb)

===== end gdb output ======

I would like to be able to say something about this core file everyone seems to deem more reliable in debugging than gdb, but I don't really know how I can obtain it. I'm running ubuntu 7.10 (gutsy).
I won't be able to debug the sunos version for a few days yet, as we only use those machines for classes, but it seemed it was the same problem: drawterm in, then start acme, navigate to wc.c (this is actually not the only file that induces this behaviour), and drawterm segfaults.
Thanks for the help!

Re: [9fans] drawterm segfault

[Sander van Dijk]

On 10/14/07, johnny@sorosj.hd.free.fr <johnny@sorosj.hd.free.fr> wrote:
> I would like to be able to say something about this core file everyone seems to deem more reliable in debugging than gdb, but I don't really know how I can obtain it. I'm running ubuntu 7.10 (gutsy).

Run "ulimit -c unlimited" in your shell before running drawterm, or
put it somewhere in your profile. See bash(1) for details.

Greetings, Sander.

Re: [9fans] drawterm segfault

[johnny]

That worked. thanks.
The core file is huge, I've put out a bzipped version of it on http://sorosj.hd.free.fr/drawterm.core.bz2 .
Cheers!

Re: [9fans] drawterm segfault

[johnny]

I'm really sorry about the 40+ megabyte attachment the I guess finally passed through!
I've recompiled drawterm from a pretty recent cvs for the debugging symbols and it doesn't happen, so I guess something in X might not be compatible or hell knows.
though I'll get to the sunos later this week, remains that one.
Cheers