nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JMP Access Violation - Likely Causes?

unknown

If it's possible to answer this question - and of course it may not be - what are likely causes of a fatal error message that states that "JMP has performed an access violation and will close down", please? For example, should I be looking out for an attempt to write data to a table that's locked, or something like that?

I've hit this problem every now and again during assorted scripting exercises over the years, and never really managed to pin down the reason for it. Usually I manage to isolate the block of script within which the fatal error evidently occurs, and simply rewrite it a different way, after which the problem disappears. As my scripting's improved over time I've encountered fewer and fewer such problems, but I still get one every now and then - and I'm looking at one right now in the middle of a quite complex script and wondering where to start.. Are there any likely causes I ought to be looking out for, or any dubious scripting constructions that are likely to generate such an error?

Many thanks

Accepted answers

danschikore

If you have a script that demonstrates the crash, please do send it to JMP Technical Support.

All comments

jenkins_macedo

I had this same issue twice in an hour.

David_Burnham

An access violation can occur any time an invalid memory operation occurs, I'm not sure I've seen any particular pattern, but JMP seems incredibly robust to table operations so that's probably the last place I would look. The problem of course if its hard and tedious to diagnose the location of the problem. I usually place a Throw() in my code to try and abort execution before the crash occurs. Then by moving the position of the Throw I can home-in on the area of code that is causing the problem. Sometimes I have done something clearly stupid, other times it might be a couple of mistakes which in combination are catastrophic.

Here is an example. A modal window is created with a handler for the validate event - the handler returns 1 or 0 indicating whether or not the window should close when OK is clicked:

New Window("Test", <<Modal,

<< On Validate(

txt = Trim(teb << Get Text);

If (Length(txt) > 0,

isValid = 1

isValid = 0

);

// return

isValid

Lineup Box(NCol(1), Spacing(10),

Text Box("Enter something, anything, but something:"),

teb = Text Edit Box("")

)

This works fine, you can run it without crashing JMP! When we write a function or an event handler then the last thing evaluated is what gets returned (see Glue to understand why). But at some point JMP introduced a Return function which makes "returning" more explicit - it works with functions but not event handlers like above. So replacing isValid with Return(isValid) in the last line of the OnValidate will not work. But JMP won't crash. But if I were to mistakenly use the OnClose event then JMP gets unhappy and will give me an access violation:

// dont try this at home

New Window("Test", <<Modal,

<< On Close(

txt = Trim(teb << Get Text);

If (Length(txt) > 0,

isValid = 1

isValid = 0

);

Return(isValid)

Lineup Box(NCol(1), Spacing(10),

Text Box("Enter something, anything, but something:"),

teb = Text Edit Box("")

)

ron_horne

i also came across this problem. in my case it was very difficult to detect the cause since the whole script was a big loop and it would crash only after 20 or 30 individual runs. and this was after i made the script as robust as possible. at the end i found that if i mention the objects each time the program don't crash.

for example:

don't do this -

dt10i << go to( :Event Duration ) << Move Selected Columns( After( “Event Date” ) ) << go to( 2 ) << Clear column Selection;

do this instead:

dt10i << go to( :Duration );

dt10i << Move Selected Columns( After( “Date” ) );

dt10i << go to( 2 );

dt10i << Clear column Selection;

i didn't find this issue documented and but i am sure i isolated it and it was the cause for the program crash in my case.

David_Burnham

JMP allows you to send multiple messages in 1 line of code but I there is no point in doing it - it's ugly, has ambiguous meaning, and makes debugging impossible. So maybe JMP crashes are just a reminder to us to try and write decent code!

jenkins_macedo

Thanks for the inputs. I think in the case the problem wasn't associated in anyways with whether or not a code was good or bad.

jenkins_macedo

The problem was associated with the input of a text file which at the last few rows had character data in columns with numeric data. The table had over 291,000 thousand rows and those slightly misplaced data were in the last few (4) rows of the data table. I corrected those and it worked well and I have had the problem again. JMP Tech Support provided the exact row where the problem they thought happened, but after re-examining the data I found out the the input text data had few slightly misplaced data in the wrong fields.

danschikore

The problem that you report has been fixed for a future release. Please do report these issues to technical support when you see them - we try to fix crashes as soon as possible and can often help you work around the underlying problem.

danschikore

If you have a script that demonstrates the crash, please do send it to JMP Technical Support.

ron_horne

Thank you Dan for suggesting, i just filed it.

jenkins_macedo

Yes, I figured out that if you have Data Type (for example character, numeric, etc.) which should all be in different columns mixed up, you might run into this violation especially when you are dealing with large sums of data. In my case, few rows of my table was slightly overlapping, thus, i had numeric variables that should have been in the specific column with that variable name into a column that had character data type. I figured that out my carefully looking through the data table after JMP Tech Support closely identified, which rows in the data table caused the problem. Initially, they were assuming it was a system bug, but I figure out that that happened because some variables (as described previously) slightly overlapped starting from the 331,670 rows of the data table that i was working with when the crash/access violation occurred. I suggest you carefully make sure that each variable is approrpiately in the same column with the Data Type and Modeling Type the same for each of the columns. That is, you should not have a character variable in a numeric variable column. Even though sometimes we use numeric variable as character in the case of Zip Code. But, I think you got the idea. At least for my case that seems to be the problem. I solved it my just reloading the original text file and formatting the data again.