System/Interpreter/Bugs/Crashes

From J Wiki
Jump to: navigation, search
Requests: Interpreter   Bugs: Interpreter

Please restrict the headings to just two levels, with the actual bug reports placed at the top level; sign your submission using ~~~~; register the entry in the comment field below.


These scenarios crash the interpreter.


crash in u^:v when v creates a gerund with infinite recursion

The second crash reported in the [[../Bugs06#crashoninfiniterecursion|'06 crash on infinite recursion report]] is still outstanding. That is, f^:] 0&]`] crashes J.

-- Dan Bron <<DateTime(2006-09-14T14:53:07Z)>>

  • Update: The sentence f^:] ]`] (in general, f^:a b`c or f^:a~ b`c where a,b, and c are identity functions, i.e. (-: 1&|.)@:(, a , b , c)) also crashes, but I haven't spent the time to analyze whether it's for the same or different reasons.

This related crash occurs in the same environment as reported above

-- Dan Bron <<DateTime(2006-09-18T18:29:58Z)>>

Status: open. The stack tweaks make it less likely to crash, but until we can monitor stack usage accurately it will be possible for 'stack error' to turn into a crash.


Suggestion: Declare that ^:v may not create a gerund, and treat this form as an error.


sparse of empty prefix crashes

As reported by Devon in the Forums the phrase $.\i.0 will crash J. I note that the crash is dependent upon the type of the empty array, as $.\'' does not crash.

Applies to ( 'j601/2006-11-17/17:05';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- Dan Bron <<DateTime(2007-09-25T19:56:21Z)>>

  • In J602 beta C, the phrase $.\i.0 no longer crashes. However, the result is still buggy; for example $ $.\i.0 crashes. More investigation leads to other odd effects:
   2 $. $.\i.0
|syntax error
|   2$.$.\i.0
   2 $. $.\i.0
|syntax error
|   2$.$.\i.0
   3!:0 $.\i.0
4096
   datatype $.\i.0  NB.  J crashes here.

Applies to ( ('j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

Status: open

-- Dan Bron <<DateTime(2008-01-08T22:35:16Z)>>

crash on monadic amend of boxed jmf

The following sentences will crash J:

   load 'jmf'

   fn =. jpath '~temp\crash.jmf'
   createjmf_jmf_ fn;1e4

   map_jmf_ 'F';fn

   F  =:  ;:'one two three'
   F  =:  0 1 0} F ,: ;: 'uno dos tres'
}}}   Similarly for non-boolean `m`:


   F  =:  0 2 1} F , 'uno dos tres' ,:&;: 'eins zwei drei'

The corresponding dyadic amendations do not crash (and may serve as a workaround):

   F  =:  (i{       z) (i=.I.          0 1 0)} F [ z=.;: 'uno dos tres'
   F  =:  (i{idx}a:,z) (i=.I.0~:idx=.  0 2 1)} F [ z=.   'uno dos tres' ,:&;: 'eins zwei drei'

Which may indicate that this is a conflict between JMF and [[JDic:../release/iamend|special code for item amend]] (though I'm not positive the sentences above trigger the special code; though I checked that the crashes still occur even if all nouns are assigned on separate lines; that is, F=: c}F,:y and F=:c}F,y0,:y1).

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

Status: open

-- Dan Bron <<DateTime(2007-11-02T17:37:25Z)>>

long train crash

J will crash when it attempts to build a long train. For example, any of the sentences a=.(139792$-`-)`:6, (419382$'-') 128!:2 'a' or ".'a=.',139788$'-' will crash J. In each case, if you decrement the large integer, J will not crash.

Note that the second example makes it obvious that the building of the verb, not execution of it, causes the crash (the absence of a domain error for -'a' indicates this; shorter trains do produce that error). The assignments in the other two examples are only merely to prevent J from (trying to) display the verb and getting an out of memory exception before it can crash.

I think these examples indicate the bug is in the maximum depth of J's parse tree. If that's the case, then a limit or stack error is preferred, as in the cases + 1 :(}:^:('@'-:{:)65535$'-@') and (39998$'-') 128!:2 'a' respectively.

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- Dan Bron <<DateTime(2007-11-15T20:07:44Z)>>

    • Even though neither a=.(139791$-`-)`:6 nor ".'a=.',139788$'-' will crash J independently, in sequence they will:
   a=.(139791$-`-)`:6
   ".'b=.',139787$'-'  NB.  J crashes here
 Obviously, this is related to the re-assignment of a (it won't occur if the second assignment is to another name), but I'm not sure if it's a distinct bug or if the initial assignment to a made J skittish (trashed its memory).

Status: open

-- Dan Bron <<DateTime(2007-11-15T20:20:36Z)>>

deep conversion crash

While trying to work around the train length limitation reported earlier, I came across the crash demonstrated below. I basically manipulate 3!:1-style strings to create a very long train; when I subsequently use 3!:2 to convert the string into an atomic representation, the interpreter crashes.

Since I am using 3!:2 on a string not directly the result of 3!:1, I am not certain that this is a bug in the interpreter. OTOH: since is the atomic rep of a repetitive train, it is self-similar (i.e. it has a recursive structure). I can apply 3!:2 successfully to any string which is a precursor to the one which crashes; there's nothing special about the "last one". The string is merely longer, representing a deeper object (though maybe my pointers are out of bounds?).

Since the crash occurs before I get a chance to apply 5!:0 to the atomic rep, I don't believe it is the same as the "train crash". But I cannot verify that it is 3!:2, and not the (deeply nested) boxed structure itself which is the problem, as attempts to directly generate the structure in J are frustrated by system limitations (e.g. "out of memory" errors).

Here is the verb that crashes:

   tn  =: 4 : 0
   NB.!  Not general.

        H =. 176
        J =. H -~ # T =. 3!:1 y

        I =. 156 + +/\  0 4 8   4
        D =.           30 1 1 _17
        j =. 0.5

        for. i. x do.

            f     =. H }.T

            i     =. I + J * j =. +: j
            t     =. a.{~D + a.i. i{T

            T     =. t i}T
            T     =. T,f

        end.

        T
)

Here is a demonstration that it works correctly:

   seed =. - - - - -
   S    =: {. 5!:1 seed`''

   (3!:2 ] 0 tn S) 5!:0
- - - - -
   (3!:2 ] 1 tn S) 5!:0
- - - - - - -
   (3!:2 ] 2 tn S) 5!:0
- - - - - - - - - - -
   (3!:2 ] 3 tn S) 5!:0
- - - - - - - - - - - - - - - - - - -
   (3!:2 ] 4 tn S) 5!:0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   NB.  Etc

   S15 =: 15 tn S      NB.  Executes properly, returning a  3!:1
   s15 =: 3!:2 S15     NB.  Convert to atomic rep
   v15 =. s15 5!:0     NB.  Evoke atomic rep
   4!:0 v15`''         NB.  It's a proper train (of about  2^16  verbs).
3

and here is how to use it to make J crash:

   S16 =: 16 tn S      NB.  Executes properly, returning a  3!:1
   s16 =: 3!:2 S16     NB.  J crashes here.  Can't convert to atomic rep.

I've had it crash on the argument 15 as well (but never on an argument of 14 or less). The problem may be related to available system memory (I don't think it has to do with the magic number 16, but I could be wrong).

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)


    • Actually, the fact that 16&train crashes is pretty suspicious. The number of verbs in the train grows as 3 + 2 ^ >:. A couple of the train crashes occur at a length of ~ 139792, and I notice that:
   (3 + 2 ^ >:)^:_1: 139792
16.0929
 So perhaps this bug isn't directly in the parser, but in a more general limitation on the depths of trees J can represent internally (around 2^16; perhaps a two-byte limit somewhere?).

That wouldn't explain the crash on 15&train, however. But I cannot now reproduce that error, so it may have only occured in an older version of tn which (erroneously) produced extra boxing. Therefore the old version of tn might have been as deep (or deeper) at 15 than the current version is at 16.

Status: open

-- Dan Bron <<DateTime(2007-11-15T21:13:47Z)>>


tall stack crash

The following crashes J:

   p=: 3 : 0
   	m=.(3 #:@:+ [: i.@<:&.-: 2^#) y
   	c=.m <@:p;.2"1 y
)

   p;:'a b c'

I believe this is an instance of the recursion limit bug. I'm aware that [[JDic:../release/recurlim|J6.01 eased this problem]], but that some vestiges remain and are difficult to address.

OTOH, the nature of the bug makes examples hard to minimize, so I'll report it anyway, in case the bug is novel or unique.

A few things I did notice:

    • The cut mask is germane:
      p=: 3 : 0
   	m=.1
   	c=.m <@:p;.2"1 y
)

   p;:'a b c'  NB.  Hang, not crash.
 *  A debugging statement reveals the crash occurs at the 6483rd invocation of the verb
   t =: ;<@:(3&}.);.2 (9{a.)-.~ 0 :0
	   N=: 0
	   p=: 3 : 0
	   	1!:2&2 N =: N + 1
	   	m=.(3 #:@:+ [: i.@<:&.-: 2^#) y
	   	c=.m <@:p;.2"1 y
	   )
	   p ;:'a b c'
)
   {:];._2 t spawn 'jconsole' [ load 'task'
6483
}}} which approximates J's stack depth:


   $:@:>: ::]0
6666

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- Dan Bron <<DateTime(2007-11-19T14:54:33Z)>>

Status: caused by running out of stack; needs accurate stack accounting


-- Dan Bron <<DateTime(2008-01-08T21:55:42Z)>>


uninvestigated display crash

I encountered a crash today. You can reproduce it with this script. I will investigate further later; I am leaving this report as a reminder to myself, and so that you may investigate independently (if you choose).

I believe the bug is in the display of the resulting array, because J will not crash if the script to is modified by replacing the ultimate smoutput ... with A=: ... .

Applies to ('j602/2008-03-03/16:45';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

Status: uninvestigated

-- Dan Bron <<DateTime(2008-07-15T20:42:09Z)>>

sparse polynomial crash

J crashes when dyad p. is supplied a sparse argument. For example, the following sentences crash J:

NB.  Large sparsely populated integer array
D  =:  (1+?138#100) (($A) <@#: ?. 138 # */$A)}A=:400 400 $ {.0 2

NB.  Sparse-array equivalent
S  =: $. A

NB.  Polynomial application
S p. 12     NB.  J crashes here

J also crashes if the arguments to p. are reversed. However, no crash occurs if D is substituted for S (i.e. if both arguments are dense).

Status: open

-- Dan Bron <<DateTime(2008-11-05T14:10:47Z)>>

$.^:_1 d. 1 runs out of memory

-- Henry Rich <<DateTime(2014-04-19T15:49:56Z)>>

Status: open.

p:^:_1 d. 1 runs out of memory

-- Henry Rich <<DateTime(2014-04-19T15:49:56Z)>>

Status: open.

] d. (1 2,:3 4) 3 freezes

-- Henry Rich <<DateTime(2014-04-19T19:42:50Z)>>

Status: open.

$. or e. crashes

a1=: a2=: 1 $. 10 ; 0 ; 0
del=: (3 : 'a1=: 8 $. a1')^:(e.&2) [ (3 : 'a2=: 8 $. a2')^:(e.&1)  NB. (e.)'s args are confused
del 1 2  NB. SIGSEGV

-- Igor Zhuravlov <<DateTime(2018-01-15T12:13:24Z)>>

Status: open.