Hi,
I received a report that the gnulib "checking whether strcasestr works
in linear time" configure test on MacOS hangs for "3 to 4 hours"
before completing. Presumably this means the alarm() call in the test
doesn't work.
The version of gnuit with the problem is at:
http://erislabs.net/ianb/tm
Ian Beckwith wrote:
> I received a report that the gnulib "checking whether strcasestr works
> in linear time" configure test on MacOS hangs for "3 to 4 hours"
> before completing. Presumably this means the alarm() call in the test
> doesn't work.
Presumably, yes...
> The version of gnuit with th
On Mon, Jun 09, 2008 at 12:42:18AM +0200, Bruno Haible wrote:
> On which MacOS X version was this? It configures fine and quickly for me
> on MacOS X 10.3.9 and 10.5.2.
Erm, don't know, I'll ask.
In case you can map kernel versions to MacOS versions, config.log
says:
uname -v = Darwin Kernel Ver
Ian Beckwith wrote:
> In case you can map kernel versions to MacOS versions, config.log
> says:
>
> uname -v = Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008;
> root:xnu-1228.4.31~1/RELEASE_I386
That's MacOS X 10.5.2, the mainstream MacOS X.
> > > http://erislabs.net/ianb/tmp/config.
Bruno Haible clisp.org> writes:
> The config.log shows nothing unusual, other than
> "checking whether strcasestr works in linear time ... result: yes"
>
> Two questions:
> - Was the configuration running in some kind of virtual processor/machine
> (Parallels, QEMU, VirtualBox, VMware Fusion,
Eric Blake <[EMAIL PROTECTED]> writes:
> Does adding a call
> to "signal(SIGALRM,SIG_DFL);" prior to the alarm() in the test case help?
Good point. And thanks; I think you've found the problem. But even
if you haven't, that change sounds worthwhile even if it doesn't fix
this particular bug.
> Could it be that the process was started with SIGALRM inherited as ignored?
I'm betting this is the case, as I was able to reproduce a "hanging"
configure on OpenBSD with:
trap '' ALRM; ./gnulib-tool --with-tests --test strstr
And explicitly resetting SIGALRM in the .m4 files avoided the hang
Ian Beckwith erislabs.net> writes:
> I received a report that the gnulib "checking whether strcasestr works
> in linear time" configure test on MacOS hangs for "3 to 4 hours"
> before completing. Presumably this means the alarm() call in the test
> doesn't work.
Actually, it's our ploy to get pe
Eric Blake wrote:
> > Could it be that the process was started with SIGALRM inherited as ignored?
Thanks for the fix.
> The corresponding tests/test-strstr.c and friends can continue to
> use alarm() in an environment with SIGALRM ignored, rather than
> also doing the signal reset, because a) we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 6/9/2008 7:03 PM:
|> The corresponding tests/test-strstr.c and friends can continue to
|> use alarm() in an environment with SIGALRM ignored, rather than
|> also doing the signal reset, because a) we should already be usin
Eric Blake wrote:
> Go ahead and make the change if you feel better about it that way.
Thanks. Yes, it feels safer this way. Applied:
2008-06-10 Bruno Haible <[EMAIL PROTECTED]>
* tests/test-memmem.c (main): Reset SIGALRM to default handling before
using alarm().
* tes
On Mon, Jun 09, 2008 at 03:34:09PM -0700, Eric Blake wrote:
> And explicitly resetting SIGALRM in the .m4 files avoided the hang.
> I'm committing this.
Great, that fixed it.
Thanks!
Ian.
--
Ian Beckwith - [EMAIL PROTECTED] - http://erislabs.net/ianb/
GPG fingerprint: AF6C C0F1 1E74 424B BCD5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 6/10/2008 4:13 AM:
| Eric Blake wrote:
|> Go ahead and make the change if you feel better about it that way.
|
| Thanks. Yes, it feels safer this way. Applied:
But you forgot to include , and calling signal() without
prot
13 matches
Mail list logo
