Hello Chris, The session blocking was my fault. Sorry for having you mislead on this.
I used 'libedif.so' ⎕fx 'edif2' instead of 'libedif2.so' ⎕fx 'edif2' -- However, the latest version still segfaults on 'libedif2.so' ⎕fx 'edif2' 'libedif2.so' ⎕fx 'edif2' )off and 'libedif.so' ⎕fx 'edif2' 'libedif.so' ⎕fx 'edif2' )off Best regards, Hans-Peter Am 20.08.2018 um 18:48 schrieb Chris Moller: > Yet another bugfix committed to https://github.com/ChrisMoller/edif.git > > Mostly, what it does is detect multiple ⎕fx invocations of libedif2.so > and short-circuits them, leaving the inotify() process intact and the > message queue opened only once. It also detects )clear and > closes/unlinks the queue, kills the inotify() process, and closes any > open editor processes. > > Chris > > On 20/08/18 10:38, Hans-Peter Sorge wrote: >> >> Hello Chris, >> >> The session stays blocked - what ever I try fiddling around. >> >> During this fiddling I came across on other situation that makes the >> edif2 case even more interesting: >> >> (EDIF2 is a work space having edif2 as function only) >> >> The first session (eg. after reboot) has a double free corruption in >> either case. >> 1) 'libedif.so' ⎕fx 'edif2' .. 'libedif.so' ⎕fx 'edif2' .. )off >> or >> 2) )load a WS having function edif2 then 'libedif.so' ⎕fx 'edif2' .. >> )off >> >> >> [joy@joyw520 ~]$ apl >> >> 'libedif.so' ⎕fx 'edif2' >> edif2 >> >> )clear >> CLEAR WS >> )load EDIF2 >> SAVED 2018-08-20 16:03:15 (GMT+2) >> 'libedif.so' ⎕fx 'edif2' >> edif2 >> )off >> double free or corruption (fasttop) >> Abgebrochen (Speicherabzug geschrieben) >> >> >> The following case is not expected. Yet one could argue )save does >> some cleaning. >> >> [joy@joyw520 ~]$ apl >> >> 'libedif.so' ⎕fx 'edif2' >> edif2 >> )save EDIF2 >> NOT SAVED: THIS WS IS CLEAR WS >> )drop EDIF2 >> 2018-08-20 16:10:32 (GMT+2) >> )save EDIF2 >> 2018-08-20 16:10:36 (GMT+2) >> 'libedif.so' ⎕fx 'edif2' >> edif2 >> )off >> >> Goodbye. >> Session duration: 133.863 seconds >> >> >> But now, on a naked WS, the corruption is gone .... sofar I could not >> repeat a subsequent corruption until after a reboot! >> >> [joy@joyw520 ~]$ apl >> >> 'libedif.so' ⎕fx 'edif2' >> edif2 >> 'libedif.so' ⎕fx 'edif2' >> edif2 >> )off >> >> Goodbye. >> Session duration: 6.48602 seconds >> >> Best regards, >> Hans-Peter >> >> Am 20.08.2018 um 05:26 schrieb Chris Moller: >>> Hi, Hans-Peter, >>> >>> That quirk where you quad-fx edif2 twice... >>> >>> When edif2 starts, it fork()s a process to watch for changes in the >>> working-file copies of the functions passed to emacs, and it also >>> opens a POSIX message queue so the monitor process can communicate >>> changes to APL. When you quad-fx-ed edif2 twice, all that was >>> duplicated--two monitor processes, another sender on the queue, and >>> more signals being emitted. I've put a patch in (but haven't >>> committed it yet, and it should fix the segfault) that prevents all >>> that, but my question is whether the "session blocked" bug happens >>> only after the second quad-fx. I just can't reproduce the blocking >>> bug here, so I'm looking desperately for some non-obvious cause. >>> >>> Thanks, >>> Chris >>> >>> On 08/18/18 15:29, Hans-Peter Sorge wrote: >>>> >>>> Hello Chris, >>>> >>>> I have just one process running. >>>> >>>> I recompiled and reinstalled edif to make sure it's the most recent >>>> version. >>>> >>>> During editing with emacs: >>>> >>>> session is blocked, then in APL session >>>> >>>> Ctrl C >>>> fg >>>> >>>> 'some data' ENTER - no response >>>> >>>> in emacs: save >>>> >>>> in APL session: >>>> 'some data' replayed >>>> 'some data' response >>>> >>>> --------------------------------- >>>> >>>> There is on other quirk too: >>>> >>>> .... >>>> 'libedif.so' ⎕fx 'edif2' >>>> edif2 >>>> 'libedif.so' ⎕fx 'edif2' >>>> edif2 >>>> )off >>>> double free or corruption (fasttop) >>>> Abgebrochen (Speicherabzug geschrieben) [segmentation fault] >>>> >>>> Best regards, >>>> Hans-Peter >>>> >>>> >>>> Am 18.08.2018 um 02:39 schrieb Chris Moller: >>>>> >>>>> I can't make it fail, but I'll look closer in the morning. >>>>> >>>>> Is there any chance you have multiple APL processes running >>>>> concurrently? Apparently, that causes problems I hadn't caught before. >>>>> >>>>> >>>>> Chris >>>>> >>>>> >>>>> On 17/08/18 17:14, Hans-Peter Sorge wrote: >>>>>> >>>>>> Hello Chris, >>>>>> >>>>>> edif2 blocks the apl session again. >>>>>> >>>>>> edif: latest git. >>>>>> >>>>>> apl: 1069M >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Hans-Peter >>>>>> >>>>>> >>>>>> Am 16.08.2018 um 21:31 schrieb Chris Moller: >>>>>>> >>>>>>> Not that I expected otherwise, but edif and edif2 still work as >>>>>>> expected. >>>>>>> >>>>>>> cm >>>>>>> >>>>>>> >>>>>>> On 16/08/18 15:14, Juergen Sauermann wrote: >>>>>>>> Hi Hans-Peter, >>>>>>>> >>>>>>>> thanks, hopefully fixed in *SVN 1069*. >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> /// Jürgen >>>>>>>> >>>>>>>> >>>>>>>> On 08/16/2018 07:29 PM, Hans-Peter Sorge wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> The ⎕IO bug is back. >>>>>>>>> >>>>>>>>> (note: ⎕IO ←→ 0 seems to be set to 0 using edif2) >>>>>>>>> >>>>>>>>> >>>>>>>>> ∇qio_test[⎕]∇ >>>>>>>>> >>>>>>>>> ∇ >>>>>>>>> [0] qio_test >>>>>>>>> [1] ⎕IO >>>>>>>>> ∇ >>>>>>>>> >>>>>>>>> >>>>>>>>> ⎕IO←1 >>>>>>>>> ⎕IO >>>>>>>>> 1 >>>>>>>>> qio_test >>>>>>>>> 1 >>>>>>>>> ⍎¨ 'qio_test' 'qio_test' >>>>>>>>> 1 >>>>>>>>> 1 >>>>>>>>> >>>>>>>>> ⎕IO←0 >>>>>>>>> >>>>>>>>> ⎕IO >>>>>>>>> >>>>>>>>> 0 >>>>>>>>> >>>>>>>>> qio_test >>>>>>>>> 0 >>>>>>>>> ⍎¨ 'qio_test' 'qio_test' >>>>>>>>> 1 >>>>>>>>> 1 >>>>>>>>> >>>>>>>>> Greetings >>>>>>>>> >>>>>>>>> Hans-Peter >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Am 14.08.2018 um 18:17 schrieb Chris Moller: >>>>>>>>>> >>>>>>>>>> I just committed a minor patch to edif, fixing a relatively >>>>>>>>>> low probability bug involving a possible message queue name >>>>>>>>>> collision if you have two or more APL sessions open >>>>>>>>>> simultaneously. >>>>>>>>>> >>>>>>>>>> https://github.com/ChrisMoller/edif >>>>>>>>>> >>>>>>>>>> --cm >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
