Skip Menu |

This queue is for tickets about the Panda-Time CPAN distribution.

Report information
The Basics
Id: 120703
Status: resolved
Priority: 0/
Queue: Panda-Time

People
Owner: Nobody in particular
Requestors: SREZIC [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in:
  • 3.1.0
  • 3.1.1
Fixed in: (no value)



Subject: SIGABRT in test suite (debian/stretch + bleadperl)
03-tzset.t fails with perl 5.25.11 on a debian/stretch system: ... terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc t/03-tzset.t ............ All 4 subtests passed ... The summary shows that a SIGABRT happened here. I don't see the failure on other debian or freebsd systems, and it also does not happen on this debian/stretch system with perl 5.24.x.
Чтв Мар 23 03:46:47 2017, SREZIC писал: Show quoted text
> 03-tzset.t fails with perl 5.25.11 on a debian/stretch system: > > ... > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > t/03-tzset.t ............ > All 4 subtests passed > ... > > The summary shows that a SIGABRT happened here. > > I don't see the failure on other debian or freebsd systems, and it > also does not happen on this debian/stretch system with perl 5.24.x.
Hi. I've seen this but only once and could not retry it. Does it happen all the time for you? If so, could you please specify which zone tzset() was setting before it core dumped? and what is in the file which holds that zone?
On 2017-03-24 10:37:01, SYBER wrote: Show quoted text
> Чтв Мар 23 03:46:47 2017, SREZIC писал:
> > 03-tzset.t fails with perl 5.25.11 on a debian/stretch system: > > > > ... > > terminate called after throwing an instance of 'std::bad_alloc' > > what(): std::bad_alloc > > t/03-tzset.t ............ > > All 4 subtests passed > > ... > > > > The summary shows that a SIGABRT happened here. > > > > I don't see the failure on other debian or freebsd systems, and it > > also does not happen on this debian/stretch system with perl 5.24.x.
> > Hi. I've seen this but only once and could not retry it. Does it > happen all the time for you? If so, could you please specify which > zone tzset() was setting before it core dumped? and what is in the > file which holds that zone?
strace shows these lines before the SIGABRT: ... 10084 09:22:30.434090 access("/etc/localtime", R_OK) = 0 <0.000032> 10084 09:22:30.434184 open("/home/cpansand/.cpan/build/2017032609/Panda-Time-3.1.1-0/blib/arch/Panda/Time.x/payload/zoneinfo/", O_RDONLY) = 3 <0.000022> ... It looks like opening a directory (instead of a timezone file?) is causing the problem. On this system /etc/localtime is symlinked to /usr/share/zoneinfo/Etc/UTC
replaced by Time::XS, should be okay now