Yeah, I've noticed that APL gets unhappy when stdout/stderr interferes
with its pty. I tried to pull down a trial version of slickedit just to
see what was going on, but stopped when it asked me for a credit card on
which to charge 300USD, so I'm only guessing that the output you're
seeing is stdout or stderr. I did a little experiment with a dummy
"editor" (actually hello.c) just to see what happens when you dump a
lot of stuff to stderr, but that didn't cause any memory issues even
when I ran under valgrind. Something I can try would be to
close(STDERR_FILENO),and maybe close(STDOUT_FILENO) before
exec()ing--any editor edif2 can use will almost certainly use GTK+, Qt,
or something other than standard IO. (I'd use the axis form, like
edif2[1] would suppress stderr, or something similar. The "corrupted
double-linked list" message comes from malloc, so I'm guessing
unallocated memory is being stepped on, but valgrind didn't catch any of
that so I'm not sure what's causing it.
I'll look into the inotify stuff.
Chris
On 08/22/18 16:15, Hans-Peter Sorge wrote:
Hi Chris,
it' a stubborn case (the latest version).
I have an other case that fails (vs is script starting slickedit) :
#### apl ... session:
'libedif2.so' ⎕fx 'edif2'
edif2
'vs' edif2 'xxxx'
/var/run/user/2000/21616/xxxx.apl ### output from scrip vs
### output from slickedit ------------->
/opt/slickedit-pro2015/bin/vs_exe -sc /home/joy/.slickedit -sr
/home/joy/.slickedit /var/run/user/2000/21616/xxxx.apl ### slickedit
SlickEdit: An instance of SlickEdit is already being displayed on this X
server. The existing instance is being activated.
If you want to bring up a new copy of SlickEdit, use +new option.
You can turn off this message by setting
VSLICKXNOPLUSNEWMSG=1
### output from slickedit -------------<
### this is intermittent. might happen after several editor calls
'vs' edif2 'xxxx'
corrupted double-linked list
Abgebrochen (Speicherabzug geschrieben)
### session end
The message sent from slickedit seems to corrupt the memory.
The problem happened in previous version too (w/o pthread_mutex_......)
