bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Hans-Peter Sorge
Subject: Re: [Bug-apl] edif update / ⎕IO is 0
Date: Mon, 20 Aug 2018 19:03:57 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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


address@hidden ~]$ 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. 

address@hidden ~]$  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!

address@hidden ~]$ 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












reply via email to

[Prev in Thread] Current Thread [Next in Thread]