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_......) The inotify handling seems to a bit tricky. Some time ago I wanted to handle a backup any time a file got stored. But the inotify fired any time a read (the backup) was done too. So the backup initiated a backup..... The emacs file handling causes some very noisy events by inotify. My fix a that time was just conventional file monitoring. I have instrumented the edif2 function and recorded the function call. Weird are some times multiple (eg read file) events. They are not related to how many character were entered: )reset 'emacs' edif2 'xxxx' xxxxxxxxxxxxxx add_a_kid: 14252 xxxxxxxxxxxxxx cleanup: /var/run/user/2000/13196 xxxxxxxxxxxxxx get_fcn: 0x7ffc9d6b6c58 xxxxxxxxxxxxxx inotify_event: xxxxxxxxxxxxxx msg_handler: xxxxxxxxxxxxxx handle_msg: xxxxxxxxxxxxxx read_file: xxxxxxxxxxxxxx inotify_event: xxxxxxxxxxxxxx inotify_event: xxxxxxxxxxxxxx inotify_event: xxxxxxxxxxxxxx inotify_event: xxxxxxxxxxxxxx read_file: xxxxxxxxxxxxxx read_file: xxxxxxxxxxxxxx read_file: xxxxxxxxxxxxxx read_file: xxxxxxxxxxxxxx enable_mq_notify: ⍝ why 4 x inotify_event / read_file ⍝ ENTER xxxxxxxxxxxxxx inotify_event: xxxxxxxxxxxxxx msg_handler: xxxxxxxxxxxxxx handle_msg: xxxxxxxxxxxxxx read_file: xxxxxxxxxxxxxx enable_mq_notify: ⍝ save xxxxxxxxxxxxxx inotify_event: xxxxxxxxxxxxxx msg_handler: xxxxxxxxxxxxxx handle_msg: xxxxxxxxxxxxxx read_file: xxxxxxxxxxxxxx enable_mq_notify: ⍝ more data entry xxxxxxxxxxxxxx inotify_event: xxxxxxxxxxxxxx msg_handler: xxxxxxxxxxxxxx handle_msg: xxxxxxxxxxxxxx read_file: xxxxxxxxxxxxxx enable_mq_notify: ⍝ save xxxxxxxxxxxxxx inotify_event: xxxxxxxxxxxxxx inotify_event: xxxxxxxxxxxxxx msg_handler: xxxxxxxxxxxxxx handle_msg: xxxxxxxxxxxxxx read_file: xxxxxxxxxxxxxx read_file: xxxxxxxxxxxxxx enable_mq_notify: ⍝ this time 2 x read_file ⍝ leave editor xxxxxxxxxxxxxx edit_chld_handler: I hope you have some use for it. Thank You, Hans-Peter Am 22.08.2018 um 17:47 schrieb Chris Moller: > Hi, Hans-Peter, > > Something occurred to me last night... > > When edif2 starts, it fork()s but instead of exec()ing it just goes > into an inotify() read loop, That leaves two APL processes running > and when they're killed they both call the edif2 close_fun(). Among > other things, close_fun() frees various bits of malloc()ed space and > the double-free bug occurred when one or more of those spaces was > freed twice. (At least, I think that's what was happening...) My > last patch was to put in a test in before free()ing, but it occurred > to me that the test&free stuff isn't atomic so there's a small but > non-zero race window. To deal with that, I just put in another that > patch that adds a process-shared mutex to make the tests/frees > effectively atomic. (It would have been more straight forward to use > pthread_create() for the inotify() loop, but I didn't think of it...) > > No urgency, but if you want to try the patch in your environment, that > would be great. It works on my machines, but obviously that's no > guarantee. > > Thanks, > Chris > > (Now maybe I can get a good night's sleep...) > > > On 20/08/18 17:58, Hans-Peter Sorge wrote: >> >> YES - Thank You - >> >> I'll have a good night sleep now:-) >> >> Peter >> >> >
