Menu
▾
▴
1 Attachments
#2286 gnuplot crashes from access violation
Probably the same issue as #2223 and #2227
The error seems to depend either on hardware or software installed on the computer, so probably difficult to solve. I have previously run gnuplot 5.0.4 on a similar configured setup so leaning towards hardware, but can't be sure.
I tried on these gnuplot version and all seems to have the same issue.
5.2.8
5.2.6
5.2.2
Feel free to ask for info if this is something that is to be investigated further. I'll try and check up on it once in a while.
You could start by answering some of the questions I already asked in #2227, without getting any answers from that one's poster: Are you by any chance running some unusual AntiVirus or similar protection engine? Might you have got a corrupted / manipulated download?
Do you, by any chance, have the tools and experience to run gnuplot in a debugger that might show more precisely where/how this crash happens?
For those with the same issue I do have a "workaround" for it. gnuplot 5.0.4 works fine on my setup.
For questions:
- Are there any unusual AntiVirus, no turning off anti virus does not change the problem.
- Might it be a manipulated download. No that would not be the case. Source site (here) for the working 5.0.4 is the same as for the other versions I tried.
Is there a guide to run the compilation. I asume the sources are those next to the download in a zip file. I might find the time to compile and run it with a debugger, to get a line for the exception. Is visual studio fine for compiling gnuplot, as that is my current compiler.
That doesn't really answer the question asked. The important bit would have been which antivirus it is you're turning off there. It's important because depending on the tool in use, "turning off" may not actually be possible. For some of those beasts even a de-install doesn't actually turn them off completely.
Sometimes. But some of the .zip packages are actually Windows binaries. The README blurb in the release files' page tells what is what.
Instructions for building from source are in the usual place: the INSTALL file in the source tarball. But while building with MSVC does work, the release binaries are built using a different toolchain, so it would probably invalidate the intended check. There is also a whole slew of other, fat packages you would need to faithfully reproduce the release binaries (Qt, wxWindows, gd, etc.), which would make that experiment quite hard.
For the time being, it should suffice to turn on MSVC's just-in-time debugger (the thing that used to be called DrWatson) then start the release binary. That should catch the crash and allow you to see where/how it happens, even without debug information.
Last edit: Hans-Bernhard Broeker 2020-06-29
The antivirus is ESET. I doubt it will help much, but no problem giving the information.
I have never used the just-in-time debugger before and it does not seem to work for me. I might be doing something wrong as the online guide from microsoft seems to focus on a self compiled binary, and I didn't see a "good" guide for it.
From reading it seemed like it should be : Debug->Options->Debugging->Just-In-Time and turn on the option. Then run the binary that throws the exception, and visual studio would when detect it and be able to give some info. Seems odd to me there is no attach step, but I'm very used to have a debugger attached to the code I'm testing.
Well, that's not exactly a rare and unusual one, but in these days of MS Defender basically owning the Antivirus business on Windows, it does provide one possible clue as to the incidence pattern of this problem.
The other is timing: 3 very similar reports in 6 months, after years of quiet, concerning a program with thousands of downloads per week. And now you've added that it affects versions that have been out there for years That indicates the problem must be something new that happened this year, but outside gnuplot itself, and only to a rather small minority of the user base. If it were some Windows Update, e.g., then the roughly 100000 users who downloaded 5.2.8, directly from this site, would all have to be affected. If it takes running the latest ESET with a particular set of configuration options, that number might conceivably drop down to a handful.
Attaching is for debugging into programs that fail to stop, not for those have stopped by crashing. This is post-mortem debugging, more similar to running the debugger on a core-dump file left behind by a crashing program on Unixen. Windows doesn't write coredumps ... it offers the opportunity to hook a variant of the debugger into the dying process, instead.
Last edit: Hans-Bernhard Broeker 2020-06-30
ESET is for sure a unusual one, but initially thought it didn't matter as turned off.
So what is the current state for this bug? Considering how rare it is, there is probably not much value trying to fix it unless it becomes more common. For those few there is a potential "workaround" using an older version.
Thanks for the input and time spent on this feedback trying to get into more detail. Closing it for now is fine resolution for me, and this as a reference might still bring value at some point.
Well, as I hinted earlier, "turning off" is something antivirus tools are notoriously resistant to, so I wouldn't easily trust that having had the desired effect. They behave like that partly because they have to be, partly because they don't want to do allow it. Some of them are almost as hard to remove as the malware they're supposed to protect against.
It is that we have at least some possibly pertinent information now, but it will remain impossible to fix this until we get much closer to the root cause. And that will require a triple coincidence to happen: the bug to appear, on the machine of someone with solid motivation to do something about it, and that someone being skilled with the MinGW toolchain and its debugger (or willing to learn a lot, in a rather short time).
As such the bug will just have to stay open until that triple coincidence happens.
Related: [#2223] and [#2227]
All of these are potentially related to initialization issues discussed in [#2304] and [#2301]. For now, I consider this a duplicate of these. Please let me know of if creating a wgnuplo.ini as described in [#2402] helps.
Related
Bugs:
#2223Bugs:
#2227Bugs:
#2301Bugs:
#2304Bugs:
#2402@mortentg the issue should be fixed in version 5.4.2. It would be great if you could confirm that.
I can confirm I can start version 5.4.2 without crashing, so indeed seems like a duplicate of mentioned tickets.
So looks fixed to me :)