[gs-bugs] [Bug 691995] Command line works, DLL does not

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Tue Feb 22 18:48:09 UTC 2011


http://bugs.ghostscript.com/show_bug.cgi?id=691995

--- Comment #3 from Marcos H. Woehrmann <marcos.woehrmann at artifex.com> 2011-02-22 18:48:06 UTC ---
Ken had some suggestions/comments:

Our executable *also* uses the DLL (unless they've built the 'big executable'
which seems unlikely). So what they are comparing is their executable using the
DLL against our executable using the DLL. Ours works, theirs doesn't, which
rather points the finger at their implementation somehow. (I'm assuming that
they are using our built DLL and not building it themselves.)

The only interesting piece of information is the error value (0x3E6), which
isn't a Ghostscript error, if it is a system error then it is error #998
'ERROR_NOACCESS' which indicates an invalid access to a memory location.

Assuming that to be the case, then it is likely a memory error (buffer overrun,
memory corruption, access to freed memory etc). The reason it exhibits when
using their executable and not ours is because the DLL executes in the address
space of the parent process. Obviously memory locations will be different in
their process.

Its not really possible for us to debug this without having the code for the
process which provokes the issue. Also debug builds often don't exhibit the
problem either, because the address layout changes. These kinds of problems are
something of a nightmare.

At present the best suggestion I can make is that they upgrade to a newer
version. I've fixed several memory problems over the years since the release of
8.64 (or 8.70, which ever they are actually using) and I'm sure the other
developers have too. Its possible that the problem has been fixed already.

Its also possible it hasn't.


It looks to me like their application is trapping the exception and reporting
it, to prevent the usual Windows crash dialog. The first thing I would suggest
is that they try running their code without that to verify that what I'm saying
is true. If it is they should get a crash dialog.

After that, its up to them what they want to do. They could send us the binary
for their (modified to crash) application and we could try and see if we can
get a crash here, if we can we could try using a DLL with symbols (but still
optimised) and a just-in-time debugger. That might tell us where the crash
happens and might enable us to identify whether a fix exists. We would
absolutely have to know *precisely* which version of Ghostscript they are
using, as we would need to build a DLL with symbols to do the test. Even the
slightest deviation of the code could cause the problem to vanish as memory
locations change.

They could send us the source to their application and we could try fully
debugging it but I have to say its not very likely to be much more helpful than
having their binary. The most likely thing is that we debug it, find its a
crash in the garbage collector and then have to shrug and say 'well its
*probably* fixed in a later revision'

The other thing they can do is upgrade to a newer version of Ghostscritp and
hope the problem has been fixed. The trouble with that one is that the memory
locations will have moved (because we've changed the code) and so the problem
might still be present, just masked.


Pretty much all of the above is speculation based on the error return value
though. You might want to mention to their developer that there is a Windows
API call 'FormatMessage' which will turn system error numbers into human
readable strings and that might be more useful than an opaque number.....

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list