1. Calling dll function causes program to end
- Posted by ryanj Jan 04, 2014
- 1484 views
What would cause a euphoria program to just die with no explanation whenever i try to call a certain function in a dll file? The function is supposed to return an error (or success), but it just ends the program. No machine exception, no error message. It just....ends.
2. Re: Calling dll function causes program to end
- Posted by ghaberek (admin) Jan 04, 2014
- 1445 views
What would cause a euphoria program to just die with no explanation whenever i try to call a certain function in a dll file? The function is supposed to return an error (or success), but it just ends the program. No machine exception, no error message. It just....ends.
Typically that would be associated with a machine-level crash or some other out-of-range memory access attempt. Which function in which DLL are you calling?
Make sure you mind your pointers (don't pass a value that should be a pointer to a value, or vice-versa). Can you provide the function signature?
-Greg
3. Re: Calling dll function causes program to end
- Posted by ryanj Jan 04, 2014
- 1535 views
Apparently, i needed to add a '+' to use the cdecl calling convention. Now it gives me an error instead of crashing. At least that's progress. I'm making a wrapper for portaudio. The function is Pa_OpenDefaultStream(). I seem to be calling it correctly now, but the function is returning an error code. I need to find out what error that is...
4. Re: Calling dll function causes program to end
- Posted by ryanj Jan 04, 2014
- 1429 views
I got it to open a stream and start the stream, but it calls the callback function (to stream the audio buffer) exactly 1 time, then dies with no error.
5. Re: Calling dll function causes program to end
- Posted by ryanj Jan 04, 2014
- 1425 views
Ah, i forgot i also had to do this:
callbackaddr = call_back({'+', streamCallback})
Now it runs. I still don't hear audio, though. Another interesting thing i discovered: if i call task_yield() while the audio stream is running, it dies with no error. I'm curious what task_yield() does that would cause problems with a callback.
6. Re: Calling dll function causes program to end
- Posted by ghaberek (admin) Jan 05, 2014
- 1488 views
Now it runs. I still don't hear audio, though. Another interesting thing i discovered: if i call task_yield() while the audio stream is running, it dies with no error. I'm curious what task_yield() does that would cause problems with a callback.
I believe task_yield() moves the internal stack pointer, which is probably affecting a threaded asynchronous call to your callback function. Matt or Jim can probably shed more light on this. It sound obvious when I say it, but it's been my experience that multitasking is generally not thread-safe. And the thread safety of PortAudio is currently unspecified, with the note that "calls to open and close streams are definitely not thread safe on any platform."
-Greg
7. Re: Calling dll function causes program to end
- Posted by m_sabal Jan 05, 2014
- 1402 views
I've had this problem once in a while on Linux where some socket operations would activate a kernel bug, killing the process. I think that was mostly in the 2.6 kernels, though. Haven't seen it in a long time.
8. Re: Calling dll function causes program to end
- Posted by mattlewis (admin) Jan 06, 2014
- 1337 views
Ah, i forgot i also had to do this:
callbackaddr = call_back({'+', streamCallback})
Now it runs. I still don't hear audio, though. Another interesting thing i discovered: if i call task_yield() while the audio stream is running, it dies with no error. I'm curious what task_yield() does that would cause problems with a callback.
Most DLLs aside from the ones provided by Windows will probably use cdecl. That's generally the default for C compilers.
On Windows, tasks are implemented using Fibers, which are cooperative multitasking constructs for Windows. They're actually quite analogous to euphoria's tasks. Odd things can happen if you mix these with treads. If we eventually get true multi-threading, I think we'll have to switch to using threads for euphoria tasks (which we already do on non-Windows platforms).
We no longer to any low level manipulation of the stack (which was really only done for translated code). Current operating systems thwart this sort of thing as it looks like stack smashing or something similarly malicious.
Matt
