[BRLTTY] Crasher/memleak on OpenSolaris

[Willie Walker]

Thanks Dave!

Without another braille display, I'm not sure how to use another driver 
other than the X Windows driver.  I just tried the X Windows driver and 
also notice the stack size increasing at about the same rate (~0.5Mb/min).

Sorry I missed the --disable-stripping option.  Works like a charm now.

In any case, this seems to look more like a memory leak that some other 
crash.  The death at a stack size of 10240 seems to coincide rather 
nicely with with the output of ulimit:

root at opensolaris:~# ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
open files                      (-n) 256
pipe size            (512 bytes, -p) 10
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 29995
virtual memory          (kbytes, -v) unlimited

Will

Dave Mielke wrote:
> [quoted lines by Willie Walker on 2009/08/19 at 11:26 -0400]
> 
>> 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.
> 
> Can you please try with another driver or two in order to determine if the 
> problem is witihn the Baum driver or elsewhere?
> 
>> 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):
> 
> Configure with --disable-stripping.
>