Hello Chris, ==== remark
I am still puzzled - or better I have no clue .... -- The intermediate output is being written to the terminal by stdout / stderr. -- within an apl session I can scroll back and forth. The additional lines from the above mentioned output might interfere with with apl internal scrolling. A wild guess. ==== new case There is an other newly discovered quirk in a new apl session: 'libedif2.so' ⎕fx 'edif2' edif2 )load times SAVED 2018-08-16 22:46:27 (GMT+2) ^[[A^[[A^[[A ⍝ The cursor gets stuck before ^ instead of cursor moves I get control sequences ⍝ An ENTER fixes this. ==== more findings Next: Lots of "again" lines ( about 71, shortened ) [joy@joyw520 ~]$ apl )load times SAVED 2018-08-16 22:46:27 (GMT+2) 'libedif2.so' ⎕fx 'edif2' edif2 ⍝ so far so good )fns Minutes edif2 times ⍝ start editing edif2 'times' ⍝ output from edif2: again ........... several lines again ⍝content of times: ∇times[⎕]∇ ∇ [0] times [1] ## 02:00 ........... similar lines [42] ## 02:15 [43] [44] [45] ∇ ⍝ output from edif2: edif2 'times' again ........... several lines again ⍝ output from edif2: 'emacs' edif2 'times' again ........... several lines again ⍝ and then - bingo 'emacs' edif2 'xxxx' Speicherzugriffsfehler (Speicherabzug geschrieben) ---- looks like the memory corruption is related to the additional, non apl output. The "again" output is related to the "mq_send" command. When I edit the function a second/third/... time, the mq_send section gets into an infinite loop. When I reduce the number of lines in above times function to 32 the "again" output disappears. I hope this helps somehow to get closer to the root cause. Best Regards Hans-Peter Am 23.08.2018 um 06:23 schrieb Chris Moller: > 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_......) >> >> >
