[BRLTTY] Crasher/memleak on OpenSolaris

[Willie Walker]

Hi All:

When running BrlTTY from svn trunk on OpenSolaris with my Baum Vario 40 
display, I'm noticing that it seems to reliably crash after about 15-20 
minutes, regardless of whether I connect to the braille display or not. 
  I also notice this with BrlTTY 4.0.

What I'm doing is running the following command in one shell and then 
just letting brltty sit there:

pfexec brltty -d serial:/dev/term/0 -bbm -xno -p none -A auth=none -n

I then attach to the process in dbx and wait for the crash.  The trace I 
get is as follows (I'm trying to get better symbol/line number 
information, but I'm not sure how to do the equivalent of --enable-debug 
with the brltty autogen/configure stuff -- the 'make' seems eager to 
strip the symbols off):

(dbx) attach 6305
Reading brltty
Reading ld.so.1
Reading librt.so.1
Reading libaio.so.1
Reading libintl.so.1
Reading libnsl.so.1
Reading libsocket.so.1
Reading libc.so.1
Reading en_US.UTF-8.so.3
Reading methods_unicode.so.3
Reading libbrlttybbm.so
Reading UTF-8%UCS-4LE.so
Reading UCS-4LE%UTF-8.so
Attached to process 6305 with 2 LWPs
t at 1 (l at 1) stopped in __pollsys at 0xfee91d15
0xfee91d15: __pollsys+0x0015:	jb       __cerror	[ 0xfedfe0d0, .-0x93c45 ]
(dbx) cont
t at 1 (l at 1) signal SEGV (no mapping at the fault address) in 
readBaumPacket at 0xfecd438b
0xfecd438b: readBaumPacket+0x004b:	call     readByte	[ 0xfecd3830, .-0xb5b ]
(dbx) where
current thread: t at 1
=>[1] readBaumPacket(0x80b65e8, 0x7648057, 0x101), at 0xfecd438b
   [2] getBaumPacket(0x80b65e8, 0x7648057), at 0xfecd47c8
   [3] updateBaumKeys(0x80b65e8, 0x7648208), at 0xfecd5469
   [4] brl_readCommand(0x80b65e8, 0x3), at 0xfecd7582
   [5] api_readCommand(0x80b65e8, 0x3), at 0x8095ad2
   [6] readBrailleCommand(0x80b65e8, 0x3), at 0x808d380
   [7] runProgram(0x0, 0x8047aa8, 0x80479d0, 0x8063cfd, 0xa, 0x80479dc), 
at 0x8067182
   [8] main(0xa, 0x80479dc, 0x8047a08, 0xfeffb7b4), at 0x806aa46
(dbx)

In debugging this a little, I see that readBaumPacket is called 
constantly, so it looks like somehow somewhere a little hiccup occurs 
after 15-20 minutes.  I'm curious if something else might be probing the 
port (I have USB-dongle attached to the system), causing BrlTTY to get 
some unexpected data.

Another possibility may be a memory leak.  When I watch the brltty 
process using 'pmap -x', I see the process growing fairly quickly - 
about 0.5Mb/minute.  Here's two snapshots of the total taken 1 minute apart:

  Address  Kbytes     RSS    Anon
total Kb   12836   12812    7788
total Kb   13404   13380    8356
---------------------------------
growth       568     568     568

The growth seems to be primarily on the stack.  Here's another two 
snapshots of the stack size taken 1 minute apart:

  Address  Kbytes     RSS    Anon
07752000    9176    9176    9176
076BD000    9772    9772    9772
--------------------------------
growth       596     596     596

It seems to die when the stack reaches the interesting number of 10240.

I don't know the BrlTTY code, so I'm not sure where to start.  I noticed 
this interesting chunk in brlapi_server.c:

static void handleResize(BrailleDisplay *brl)
{
   /* TODO: handle resize */
   LogPrint(LOG_INFO,"BrlAPI resize");
}

Any thoughts?

Will