[Openmcl-devel] Crash when calling win32 function mciSendStringA on some Windows 8 Machines

[Gary Byers]

Here's an idea; it's a little bit of a stab in the dark, but worth a try.
CCL wants to be able to handle certain types of hardware exceptions (arithmetic
errors, illegal instructions, illegal memory references) that occur during
lisp program execution.  On Windows, it establishes a lisp kernel function
as the process-wide exception handler, and this function indeed is called whenever
any of the exceptions that CCL tries to handle occurs.

Unfortunately, the same exception handling mechanism is used by Windows
to handle software exceptions (things like "file not found"), and I 
discovered a few weeks ago that tries to distinguish between the hardware-
and software-exception cases was misidentifying some software exceptions
used by the MS C++ and MS .net runtimes.  If a software exception occurs
during execution of some C++/.net code, CCL's exception handler will
basically announce that an exception occured "on the foreign stack/in foreign
code", and leaves unsaid "... and what am I supposed to do about that ?".

I checked a fix for that into the trunk sources and should probably
propagate that or a somewhat better fix to the 1.9 release soon.  I
didn't update the Windows kernel binaries: we usually do that when
there's a kernel bug fix, because many people find it difficult to
build the kernel on Windows.  I did so a little while ago.

If you haven't already done so, could you try running the case that
fails for you under the current CCL trunk ?  Whether this fixes the
problem you're having or not, it's a bad though apparently somewhat
rare bug.

If this doesn't fix your problem, I don't have a good idea of what
the problem would be.  If some difference in OS version/enviroment
causes a C++ or C# runtime exception and CCL mishandles that, then
that's a clear difference between the CCL and C code.  Other than 
that, it's hard to see a differnce that could be significant.

On Thu, 1 Aug 2013, Michael Minerva wrote:

> Gary,
> Sorry for not introducing unneeded differences into the examples.
> 
> I believe these two are much more similar and still, the C++ example plays
> the sound fine and the CCL example crashes when opening the sound file:
> 
> (defparameter *open-cstr* (ccl::make-cstring "open C:\\boing.mp3 type
> MPEGVideo alias 0"))?
> (defparameter *play-cstr* (ccl::make-cstring "play 0 from 0"))?
> (progn?
> ? (external-call "mciSendStringA" :address *open-cstr* :address +null-ptr+
> :int 0 :int 0 :<INT>)?
> ? (external-call "mciSendStringA" :address *play-cstr* :address +null-ptr+
> :int 0 :int 0 :<INT>)?
> ? (sleep 5000))
> 
> 
> #include <Windows.h>
> #include <iostream>
> 
> extern char command1[] = "open C:\\boing.mp3?type MPEGVideo alias 0";
> extern char command2[] = "play 0 from 0";
> 
> int main()
> {
> mciSendStringA(command1, NULL, 0, 0);
> mciSendStringA(command2, NULL, 0, 0);
> Sleep(5000);
> }
> 
> Also, if you instead remove the Sleep from the C version it still does not
> crash (exits normally with code 0).?
> 
> --Mike
> 
> On Aug 1, 2013, at 4:36 PM, Gary Byers <gb at clozure.com> wrote:
>
>       The most obvious differences between the CCL and C versions of
>       your code are:
>
>       1) The C code sleeps after the calls to mciSendString{A] and the
>       CCL code doesn't.
>       2) The C code uses (AFAIK, I forget what the TEXT macro does in
>       this respect) static, constant strings;
>       the CCL code uses stack-allocated, dynamic-extent strings.?
>       (Note that you can use CCL:WITH-CSTRS
>       instead of an internal unexported macro, but that isn't really
>       relevant.)
>
>       If you eliminate those differences and the two versions of the
>       code behave differently,
>       that might be interesting.? (Certainly more interesting than the
>       fact that code that does
>       different things behaves differently is.)
>
>       In at least some cases, a call to mciSendString returns before
>       the operation it invokes completes.? For how
>       long after the function returs does the code that manages that
>       operation expect the string the function receives as its first
>       argument to remain valid ?? Does the fact that a string
>       allocated via WITH-CSTRS is deallocated when the WITH-CSTRS form
>       exits (and the stack addresses may be reallocated by the REPL or
>       whatever) violate assumptions made about that string's lifetime
>       ?
> 
>
>       On 8/1/13 2:28 PM, Michael Minerva wrote:
>       We have been trying to track down an issue where we
>       experience crashes on some versions of Windows 8 when
>       calling the Cocotron method play of NSSound. After digging
>       around in the Cocotron source we discovered that the play
>       function ends up calling the win32 function
>       mciSendString.?
> Next we tried to remove Cocotron from the equation to see if we
> would still experience the same crash so we created the
> following two tests:
> 
> First, we try to open and play an MP3 file by making an
> external-call to mcsSendStringA:
> 
> (ccl::with-cstr (cstr ?"open C:\\boing.mp3 type MPEGVideo alias
> 0")
> ? (ccl::with-cstr (cstr2 ?"play 0 from 0")
> ? ? (external-call "mciSendStringA" :address cstr :address
> +null-ptr+ :int 0 :int 0 :<INT>)
> ? ? (external-call "mciSendStringA" :address cstr2 :address
> +null-ptr+ :int 0 :int 0 :<INT>)))
> 
> This causes a crash during the call to open the MP3 (the first
> external call) with no errors reported to any of our consoles or
> the Windows event viewer.
> 
> Next we run the same experiment with a wav file and all works
> well and we hear the correct sound:
> 
> (ccl::with-cstr (cstr ?"open C:\\ding.wav type waveaudio alias
> 0")
> ? (ccl::with-cstr (cstr2 ?"play 0 from 0")
> ? (external-call "mciSendStringA" :address cstr :address
> +null-ptr+ :int 0 :int 0 :<INT>)
> ? (external-call "mciSendStringA" :address cstr2 :address
> +null-ptr+ :int 0 :int 0 :<INT>)))
> 
> Finally we wrote a little C++ program:
> 
> #include <Windows.h>
> #include <iostream>
> 
> int main()
> {
> mciSendString(TEXT("open C:\\boing.mp3?type MPEGVideo alias 0"),
> NULL, 0, 0);
> mciSendString(TEXT("play 0 from 0"), NULL, 0, 0);
> Sleep(5000);
> }
> 
> This program runs fine (even with the mp3) so it seems that the
> issue does not lie directly with the win32 function.?
> 
> If any Windows 8 users could try out our test code with CCL and
> let us know if they experience the same issue that would be of
> great help (I have included the sound files which you need to
> just put at c:\).
> 
> So far we have only been able to reproduce this problem on OEM
> version of Windows 8 (it never seems to happen with Windows 8
> Pro).
> 
> More generally does anyone have any clues about what might going
> on that would cause this to crash with ccl but not from C++?
> 
> Thanks a lot,
> 
> --Mike
> 
> 
> 
> =
> 
> 
> 
> 
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
> 
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
> 
> 
> 
>