--- Begin Message ---
George Foot wrote:
> On Tue, Jun 13, 2000 at 05:10:42PM -0600, Craig Matsuura wrote:
> > I have been using the real G2 SDK with allegro and linux. I have found
> > that on some RealAudio links (live links) it cause my applications to
> > crash, with a SIGPIPE.
>
> That sounds like the player is connecting, but the other side of
> the connection gets dropped, causing you to receive a SIGPIPE
> next time you write to your end of the connection. I'm not sure
> how Allegro could be influencing that though, or how your X
> server could be dropping its connection in any way dependent
> upon whether you're playing live data or not.
When I don't call allegro_init() my program runs fine. I can connect to the
site and play the streaming audio. Not all sites seem to have this problem
with allegro.
I have been debugging inside the allegro startup code. I have found myself
in xsystem.c and xwin.c. I worked my way down into (from the
_sigalrm_init(_xwin_interrupts_handler) call from inside _xwin_sysdrv_init)
_xwin_private_flush_buffers(), which calls an XSync(). I suspect that the
XServer is dying for some reason and the XSync must fail.
If I comment out the XSync and run my original program that calls
allegro_init and displays an allegro dialog. I get the following error:
X Error of failed request: BadIDChoice (invalid resource ID chosen for this
connection)
Major opcode of failed request: 129 (MIT-SHM)
Minor opcode of failed request: 1 (X_ShmAttach)
Resource id in failed request: 0x4400007
Serial number of failed request: 199
Current serial number in output stream: 77
However the streaming audio plays?
My second test program is only calling allegro_init(). I have done nothing
else with allegro. I think that allegro must be hooking an interrupt such
as SIGALRM and conflicting with the Real G2 SDK (which probable does the
same).
I think the _sigalrm_init call could be the culprit.
SIDENOTE: Even running fullscreen using non X, like framebuffer, it appears
to have an issue. (Still verifying). I only get a few things displayed.
>
>
> > So I decide to comment the line out with the iopl() call. My
> > application no longer crashes. Is there a reason for setting the iopl
> > to level 3? Is it because of the 8514 X Server?
>
> No, but we need the privileges for the same reasons -- we need
> access to the IO ports. We can ask for specific ranges, using
> `ioperm', but that only works for fairly low port numbers (I
> don't remember exactly how low). Using `iopl', we get access to
> all ports, even ones we don't actually need. This could be what
> is causing your problem -- maybe some of the other code you're
> using is writing to ports it shouldn't be touching. That seems
> unlikely though, because it would generally cause much more
> severe problems than a simple SIGPIPE.
>
> Note that `iopl' only works at all if you have root privileges
> at the time -- if your program wasn't run either by root or suid
> root, then this call should just fail. If you comment out the
> line, it will cause various Linux console drivers to stop
> working; the VGA driver needs these privileges, for instance.
> It's possible that commenting out this line turned off some
> Allegro drivers which would otherwise have interfered with the
> other code in your program.
>
> It might help if you try running your program, including the
> `iopl' call, without root privileges -- does it crash in this
> case?
>
> I'm slightly confused by your references to the X server -- if
> the code in `lsystem.c' is at all relevant to your program,
> you're not using the X version of Allegro. Perhaps you could
> clarify exactly which version of Allegro is being used, and
> whether the effects depend upon being run by root.
>
Yes, I have been using the X version of allegro. My bad, I was looking at
both lsystem.c and xsystem.c. Because running fullscreen framebuffer
appears to have a problem too.
>
> George
>
> --
> Random project update:
> 27/04/2000: AllegroGL alpha 7 released, fixing silly omission in alpha 6
> http://AllegroGL.sourceforge.net/
--- End Message ---