Re: [AD] errno = EINTR troubles - any unix experts?

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2002-09-16 at 13:20, Laurence Withers wrote:
> 
> To follow your post up, you could either:
>  - add protection for EINTR using the do {} while() construct I gave 
>    earlier. This should be added to *every* system call.

The problem is, I couldn't find one single system call which is failing
so far (see below).. but all I did was stick in printfs all over
allegro's code. Thinking about this, maybe I should even check the
return values of my printfs..

>  - if you are using glibc, then #define _GNU_SOURCE in allegro.h and
>    I think that will fix it.

I tried this, compiling the whole lib (and grabber) with -D_GNU_SOURCE -
but no difference.

I found out with my printfs though that errno gets set in box_eol() in
datedit_endmsg() in grabber.c. If I put a printf("%d", errno); before
and after the blit() command in box_eol, it says "0 4". So during the
time the blit is taking place it gets set. The attached patch fixes the
problem for me, and the datafile gets written 100% right. It's not a
real fix of course (I still have no idea what's going on) - and once
errno got set to 4 at another place. But I think I started grabber about
100 times, so I'd say the fix is for 99% of the time, as opposed to 0%
right now :)

Is there a way to make a program abort() as soon as it sees any of those
"asynchronous signals" the libc docs mention - so gdb would show a
backtrace of what is going on, and *which* system call is actually
failing?

--
Elias Pschernig

Index: tools/grabber.c
===================================================================
RCS file: /cvsroot/alleg/allegro/tools/grabber.c,v
retrieving revision 1.36
diff -u -r1.36 grabber.c
--- tools/grabber.c	14 May 2002 11:17:14 -0000	1.36
+++ tools/grabber.c	16 Sep 2002 14:26:06 -0000
@@ -3077,6 +3077,9 @@
 
    release_screen();
    show_mouse(screen);
+   
+   if (errno == EINTR)
+      errno = 0;
 }