This is the mail archive of the
mailing list for the Cygwin project.
Re: Portaudio Errors on Cygwin
Hugh McMaster wrote:
> I can successfully compile and install Portaudio in Cygwin (after
> performing autoreconf). I have been using dynamic libraries
> (specifically cygportaudio-2.dll) I can even compile my own sources.
> When attempting to run the resulting Win32 binary, I get an error,
> that I cannot even begin to make sense of.
I have no idea what portaudio is, and I'm sure I'm not alone. It's not
an official Cygwin package. I'm sure I could google it, and find its
homepage, and read a little bit about it, and maybe dig around and find
a tarball somewhere.
Even if I had that information I have no idea what options, methods, or
patches you used to compile it, or what commands or options you used to
invoke it, or what files you supplied as input, or really what you were
trying to do with it. In other words, you've given almost no useful
information. It's kind of the analog of walking into a room of complete
strangers and asking, "Hey does anyone know what's up with Steve?"
> Exception: STATUS_ACCESS_VIOLATION at eip=0048C2C0
This means there was an access violation exception. This is Windows-ese
for "Segmentation fault". It is a generic error that occurs when a
process tries to access a page of memory that it does not have access
to. This can be caused by hundreds of different things - dereferencing
a NULL or otherwise uninitialized pointer, walking off the end of an
unterminated buffer, stack corruption, and on and on. It is a very
generic symptom of a bug in the code, or a logic error in the code, or
false assumptions about the environment the code will be executing in,
or any number of other problems.
In other words, you'll have to actually debug the program. The address
of the fault (0x004xxxxx) does imply that it is happening in the main
binary image and not a DLL, but that's not a given either. Compile with
debugging symbols (-g) and use gdb and figure out what's going on. Or
use the error_start parameter of $CYGWIN to launch the debugger at the
fault instead of the default action of creating the .stackdump file.
> Stack trace:
> Frame Function Args
> 5ED4CCB8 0048C2C0 (00000000, 00290A60, 00001000, 67144A5D)
> 5ED4CCF8 67145B1F (002848E0, 5ED4CD5C, 002917F0, 00000002)
> 5ED4CDB8 671498A5 (00284890, 5ED4CDF0, 671496B0, 5ED4CDF0)
> 671496B0 61004416 (00ACEC81, 4D8B0000, 9445C708, 00000000)
A naked stack trace of self-compiled code does not do any good. We have
no idea what those addresses correspond to.
> Does anyone know what is wrong with the library file that has been
> created on Cygwin? Should I completely reinstall Cygwin?
Please forgive the following analogy.
Reinstalling is the equivalent of popping the hood, staring at the
engine for a while, then closing the hood and trying to turn it over
again -- it doesn't actually do anything to fix the underlying problem,
unless that problem was a loose hood. And if it does work it was a
coincidence, just as sometimes letting the engine cool off will allow it
to start again. But in those cases it would have also worked if you had
just sat there for a while twiddling your thumbs and so it certainly
wasn't due to opening the hood and staring.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html