Closed p5pRT closed 16 years ago
With bleedperl I get the following test failures:
t/io/pipe.....................................................FAILED--expected 24 tests\, saw 8
ext/IO/t/io_pipe..............................................FAILED--expected 10 tests\, saw 8
ext/Time/HiRes/t/HiRes........................................ ../ext/Time/HiRes/t/HiRes.t: overall time allowed for tests (90s) exceeded! FAILED--expected 38 tests\, saw 11
The following two look fishy\, but do not generate a failure:
ext/IPC/SysV/t/ipcsysv........................................# cannot proceed: semget() error: No space left on device ok
lib/CPANPLUS/t/40_CPANPLUS-Internals-Report...................Integer overflow in version at /mnt/i386/usr/local/src/bleedperl-amd64/t/../lib/version.pm line 19. # Looks like your test died just after 60. ok
With another configuration (debugging turned on\, maybe other changes too) I got another test failure:
ext/File/Glob/t/basic.........................................FAILED at test 8
Regards\, Slaven
srezic@cpan.org (via RT) wrote:
# New Ticket Created by srezic@cpan.org # Please include the string: [perl #45513] # in the subject line of all future correspondence about this issue. # \<URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45513 >
This is a bug report for perl from srezic@cpan.org\, generated with the help of perlbug 1.36 running under perl 5.10.0.
----------------------------------------------------------------- [Please enter your report here]
With bleedperl I get the following test failures:
t/io/pipe.....................................................FAILED--expected 24 tests\, saw 8
ext/IO/t/io_pipe..............................................FAILED--expected 10 tests\, saw 8
ext/Time/HiRes/t/HiRes........................................ ../ext/Time/HiRes/t/HiRes.t: overall time allowed for tests (90s) exceeded! FAILED--expected 38 tests\, saw 11
The following two look fishy\, but do not generate a failure:
ext/IPC/SysV/t/ipcsysv........................................# cannot proceed: semget() error: No space left on device ok
This at least is normal\, it's a question of resource acquisition. I think your kernel semaphore configuration is lower than the amount of semaphores the test wants to use.
That should probably be a skip()\, come to think of it.
David
The RT System itself - Status changed from 'new' to 'open'
David Landgren \david@​landgren\.net writes:
srezic@cpan.org (via RT) wrote:
# New Ticket Created by srezic@cpan.org # Please include the string: [perl #45513] # in the subject line of all future correspondence about this issue. # \<URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45513 > This is a bug report for perl from srezic@cpan.org\, generated with the help of perlbug 1.36 running under perl 5.10.0. ----------------------------------------------------------------- [Please enter your report here] With bleedperl I get the following test failures: t/io/pipe.....................................................FAILED--expected 24 tests\, saw 8 ext/IO/t/io_pipe..............................................FAILED--expected 10 tests\, saw 8 ext/Time/HiRes/t/HiRes........................................ ../ext/Time/HiRes/t/HiRes.t: overall time allowed for tests (90s) exceeded! FAILED--expected 38 tests\, saw 11 The following two look fishy\, but do not generate a failure: ext/IPC/SysV/t/ipcsysv........................................# cannot proceed: semget() error: No space left on device ok
This at least is normal\, it's a question of resource acquisition. I think your kernel semaphore configuration is lower than the amount of semaphores the test wants to use.
That should probably be a skip()\, come to think of it.
Or just lower the number of semaphores to acquire. I only seem to have three semaphores used on my system:
$ ipcs -s
Semaphores:
T ID KEY MODE OWNER GROUP
s 65536 5432001 --rw------- pgsql pgsql
s 65537 5432002 --rw------- pgsql pgsql
s 65538 5432003 --rw------- pgsql pgsql
These kernel limits seem to apply to semaphores:
kern.ipc.semaem: 16384 kern.ipc.semvmx: 32767 kern.ipc.semusz: 104 kern.ipc.semume: 10 kern.ipc.semopm: 100 kern.ipc.semmsl: 60 kern.ipc.semmnu: 30 kern.ipc.semmns: 60 kern.ipc.semmni: 10 kern.ipc.semmap: 30
Maybe one of the both limits with the value "10" are hitting here (including some kind of off-by-one error)\, because if I reduce the number of semaphores created by the test from 10 to 9\, then the test passes without problems.
I propose the following patch:
Slaven Rezic - slaven \
tksm - Perl/Tk program for searching and replacing in multiple files http://ptktools.sourceforge.net/#tksm
Slaven Rezic wrote:
David Landgren \david@​landgren\.net writes:
srezic@cpan.org (via RT) wrote:
# New Ticket Created by srezic@cpan.org # Please include the string: [perl #45513] # in the subject line of all future correspondence about this issue. # \<URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45513 > This is a bug report for perl from srezic@cpan.org\, generated with the help of perlbug 1.36 running under perl 5.10.0. ----------------------------------------------------------------- [Please enter your report here] With bleedperl I get the following test failures: t/io/pipe.....................................................FAILED--expected 24 tests\, saw 8 ext/IO/t/io_pipe..............................................FAILED--expected 10 tests\, saw 8 ext/Time/HiRes/t/HiRes........................................ ../ext/Time/HiRes/t/HiRes.t: overall time allowed for tests (90s) exceeded! FAILED--expected 38 tests\, saw 11 The following two look fishy\, but do not generate a failure: ext/IPC/SysV/t/ipcsysv........................................# cannot proceed: semget() error: No space left on device ok This at least is normal\, it's a question of resource acquisition. I think your kernel semaphore configuration is lower than the amount of semaphores the test wants to use.
That should probably be a skip()\, come to think of it.
Or just lower the number of semaphores to acquire. I only seem to have three semaphores used on my system:
$ ipcs -s Semaphores: T ID KEY MODE OWNER GROUP
s 65536 5432001 --rw------- pgsql pgsql s 65537 5432002 --rw------- pgsql pgsql s 65538 5432003 --rw------- pgsql pgsqlThese kernel limits seem to apply to semaphores:
kern.ipc.semaem: 16384 kern.ipc.semvmx: 32767 kern.ipc.semusz: 104 kern.ipc.semume: 10 kern.ipc.semopm: 100 kern.ipc.semmsl: 60 kern.ipc.semmnu: 30 kern.ipc.semmns: 60 kern.ipc.semmni: 10 kern.ipc.semmap: 30
Maybe one of the both limits with the value "10" are hitting here (including some kind of off-by-one error)\, because if I reduce the number of semaphores created by the test from 10 to 9\, then the test passes without problems.
I propose the following patch:
--- bleedperl-amd64/ext/IPC/SysV/t/ipcsysv.t Tue Jun 13 21:29:08 2006 +++ bleedperl2-amd64/ext/IPC/SysV/t/ipcsysv.t Wed Sep 19 21:49:03 2007 @@ -148\,8 +148\,11 @@ SKIP: {
use IPC​::SysV qw\(IPC\_CREAT GETALL SETALL\);
+ # FreeBSD's default limit seems to be 9 + my $nsem = 5;
Maybe 10 was chosen because it exercises problems on other platforms? So...
my $nsem = $^O eq 'freebsd' ? 5 : 10;
David
+ my $test_name = 'sem acquire'; - $sem = semget(IPC_PRIVATE\, 10\, $perm | IPC_CREAT); + $sem = semget(IPC_PRIVATE\, $nsem\, $perm | IPC_CREAT); if ($sem) { pass($test_name); } @@ -166\,8 +169\,6 @@ SKIP: { ok(semctl($sem\,0\,IPC_STAT\,$data)\,'sem data call');
cmp\_ok\(length\($data\)\,'>'\,0\,'sem data len'\);
- - my $nsem = 10;
ok\(semctl\($sem\,0\,SETALL\,pack\("s\!\*"\,\(0\) x $nsem\)\)\, 'set all sems'\);
On 19 Sep 2007 21:56:00 +0200\, Slaven Rezic \slaven@​rezic\.de wrote:
Or just lower the number of semaphores to acquire. I only seem to have three semaphores used on my system:
$ ipcs -s Semaphores: T ID KEY MODE OWNER GROUP s 65536 5432001 --rw------- pgsql pgsql s 65537 5432002 --rw------- pgsql pgsql s 65538 5432003 --rw------- pgsql pgsql
These kernel limits seem to apply to semaphores:
kern.ipc.semaem: 16384 kern.ipc.semvmx: 32767 kern.ipc.semusz: 104 kern.ipc.semume: 10 kern.ipc.semopm: 100 kern.ipc.semmsl: 60 kern.ipc.semmnu: 30 kern.ipc.semmns: 60 kern.ipc.semmni: 10 kern.ipc.semmap: 30
Maybe one of the both limits with the value "10" are hitting here (including some kind of off-by-one error)\, because if I reduce the number of semaphores created by the test from 10 to 9\, then the test passes without problems.
I propose the following patch:
Thanks\, applied as #31967.
The test failures were all caused by SIGBUS or SIGILL signals when calling a signal handler. gdb stopped at the beginning of Perl_csighandler in mg.c. So I just guessed and replaced the variable argument list with the "real" arguments needed by a sigaction handler\, and the problem vanished: all tests pass.
I am not sure if the attached patch is correct. Are there systems which need the variable argument list? If so\, then we probably need a configure test and keep also the old va_arg code.
Regards\, Slaven
On 29/09/2007\, slaven@rezic.de via RT \perlbug\-followup@​perl\.org wrote:
The test failures were all caused by SIGBUS or SIGILL signals when calling a signal handler. gdb stopped at the beginning of Perl_csighandler in mg.c. So I just guessed and replaced the variable argument list with the "real" arguments needed by a sigaction handler\, and the problem vanished: all tests pass.
I am not sure if the attached patch is correct. Are there systems which need the variable argument list? If so\, then we probably need a configure test and keep also the old va_arg code.
We'll see with the smokes. Thanks\, applied as 32012\, amended as 32013.
Rafael Garcia-Suarez wrote:
On 29/09/2007\, slaven@rezic.de via RT \perlbug\-followup@​perl\.org wrote:
The test failures were all caused by SIGBUS or SIGILL signals when calling a signal handler. gdb stopped at the beginning of Perl_csighandler in mg.c. So I just guessed and replaced the variable argument list with the "real" arguments needed by a sigaction handler\, and the problem vanished: all tests pass.
I am not sure if the attached patch is correct. Are there systems which need the variable argument list? If so\, then we probably need a configure test and keep also the old va_arg code.
We'll see with the smokes. Thanks\, applied as 32012\, amended as 32013.
That's given me some new warnings on Win32 (with VC6):
[miniperl compilation of mg.c:] ..\mg.c(1349) : warning C4020: 'PL_sighandlerp' : too many actual parameters ..\mg.c(1388) : warning C4020: 'PL_sighandlerp' : too many actual parameters
[perl compilation of mg.c:} ..\mg.c(1349) : warning C4020: 'function through pointer' : too many actual parameters ..\mg.c(1388) : warning C4020: 'function through pointer' : too many actual parameters
On 04/10/2007\, Steve Hay \SteveHay@​planit\.com wrote:
That's given me some new warnings on Win32 (with VC6):
[miniperl compilation of mg.c:] ..\mg.c(1349) : warning C4020: 'PL_sighandlerp' : too many actual parameters ..\mg.c(1388) : warning C4020: 'PL_sighandlerp' : too many actual parameters
I would have been surprised if no problem was discovered. I see in win32/win32.h: typedef Signal_t (*Sighandler_t) (int); Does change 32020 make the situation better?
Rafael Garcia-Suarez wrote:
On 04/10/2007\, Steve Hay \SteveHay@​planit\.com wrote:
That's given me some new warnings on Win32 (with VC6):
[miniperl compilation of mg.c:] ..\mg.c(1349) : warning C4020: 'PL_sighandlerp' : too many actual parameters ..\mg.c(1388) : warning C4020: 'PL_sighandlerp' : too many actual parameters
I would have been surprised if no problem was discovered. I see in win32/win32.h: typedef Signal_t (*Sighandler_t) (int); Does change 32020 make the situation better?
Yes\, that's fixed it\, thanks.
On 10/4/07\, Steve Hay \SteveHay@​planit\.com wrote:
Rafael Garcia-Suarez wrote:
On 04/10/2007\, Steve Hay \SteveHay@​planit\.com wrote:
That's given me some new warnings on Win32 (with VC6):
[miniperl compilation of mg.c:] ..\mg.c(1349) : warning C4020: 'PL_sighandlerp' : too many actual parameters ..\mg.c(1388) : warning C4020: 'PL_sighandlerp' : too many actual parameters
I would have been surprised if no problem was discovered. I see in win32/win32.h: typedef Signal_t (*Sighandler_t) (int); Does change 32020 make the situation better?
Yes\, that's fixed it\, thanks.
Does Win32 have SA_SIGINFO defined? Based on how the prototypes are defined we may\, instead of this:
#ifdef WIN32 (*PL_sighandlerp)(sig); #else (*PL_sighandlerp)(sig\, NULL\, NULL); #endif
want this:
#if defined(HAS_SIGACTION) && defined(SA_SIGINFO) (*PL_sighandlerp)(sig\, NULL\, NULL); #else (*PL_sighandlerp)(sig); #endif
It's also rather curious that at lines 1356-57 of mg.c became:
#if defined(HAS_SIGACTION) && defined(SA_SIGINFO) #endif
with nothing between the #if and #endif..
In any case\, the compile was failinng on VMS like so:
1 83084 (*PL_sighandlerp)(sig\, NULL\, NULL); ........1 %CC-E-TOOMANYARGS\, (1) In this statement\, "(*(my_perl->Isighandlerp))" expects 1 arguments\, but 3 are supplied.
HAS_SIGACTION is defined but SA_SIGINFO is not on VMS.
I went ahead and checked in my suggestion as 32027. Please holler if that breaks Win32 again. I don't know why it wouuld as it appears the whole idea of SA_SIGINFO is to indicate whether you are passing one argument or three to the handler.
Craig A. Berry wrote:
On 10/4/07\, Steve Hay \SteveHay@​planit\.com wrote:
Rafael Garcia-Suarez wrote:
On 04/10/2007\, Steve Hay \SteveHay@​planit\.com wrote:
That's given me some new warnings on Win32 (with VC6):
[miniperl compilation of mg.c:] ..\mg.c(1349) : warning C4020: 'PL_sighandlerp' : too many actual parameters ..\mg.c(1388) : warning C4020: 'PL_sighandlerp' : too many actual parameters
I would have been surprised if no problem was discovered. I see in win32/win32.h: typedef Signal_t (*Sighandler_t) (int); Does change 32020 make the situation better?
Yes\, that's fixed it\, thanks.
Does Win32 have SA_SIGINFO defined? [...] I went ahead and checked in my suggestion as 32027. Please holler if that breaks Win32 again. I don't know why it wouuld as it appears the whole idea of SA_SIGINFO is to indicate whether you are passing one argument or three to the handler.
Win32 doesn't even have HAS_SIGACTION defined\, so it's still OK after your change.
Seems to be solved now.
Slaven
@smpeters - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#45513 (status was 'resolved')
Searchable as RT45513$