Re: [Bug-apl] edif update / ⎕IO is 0

[Hans-Peter Sorge]

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
>>
>>
>