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

[Gary Byers]

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 <smb://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 <smb://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 <smb://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20130801/ac9aa833/attachment.htm>