[Openmcl-devel] Crash when calling win32 function mciSendStringA on some Windows 8 Machines
Michael Minerva
minerva at agentsheets.com
Fri Aug 9 11:59:06 PDT 2013
Hey Gary,
Sorry it took me so long to get back to you no this (I have not had access to the machine that exhibits the problem till today).
I downloaded the trunk and rebuilt the lisp kernel and retried my experiment, and the crash still occurs.
Thanks for taking a stab at this.
--Mike
On Aug 2, 2013, at 6:29 PM, Gary Byers <gb at clozure.com> wrote:
> 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
>>
-------------- 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/20130809/cd174486/attachment.bin>
More information about the Openmcl-devel
mailing list