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

[Michael Minerva]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20130801/c363d8ca/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2559 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20130801/c363d8ca/attachment.bin>