-
Notifications
You must be signed in to change notification settings - Fork 581
ASAN segfaults in lib/warnings.t #13813
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
From @khwilliamsonThis is a bug report for perl from khw@khw.(none), Our smoke reports lately have been failing tests 425 and 427 in I do not get a failure with clang 3.2, nor with valgrind. Below is the relevant portion of one such log: POE Paste with lovely alien head... format options below PROG:
|
From @greergaOn Fri, 9 May 2014, karl williamson wrote:
Simplest case is: ./miniperl -e 'getgrnam 1' The "1" is arbitrary and doesn't matter so long as the group doesn't ASAN:SIGSEGV==1106==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000045e6b0 sp 0x7fffdab8b090 bp 0x7fffdab8b8e0 T0) AddressSanitizer can not provide additional info. (with v5.19.11-36-g2e6f7c2 above and Ubuntu 13.10.) I'm not convinced it is a problem with perl, although the latest trunk of -- |
The RT System itself - Status changed from 'new' to 'open' |
From @iabynOn Fri, May 09, 2014 at 10:43:11PM -0400, George Greer wrote:
Looking at the latest ASan src code, my suspicion is that it lies there Is your host's group data source anything unusual, like LDAP say? Can you run the following gdb session on miniperl in an affected build? $ gdb ./miniperl (gdb) c (gdb) c (gdb) fin |
From @greergaOn Mon, 12 May 2014, Dave Mitchell wrote:
No, a regular boring standalone Ubuntu 13.10 system. "group: compat" in
(gdb) b perl_alloc Breakpoint 1, perl_alloc () at perl.c:196 Breakpoint 2, __interceptor_getgrnam_r () Breakpoint 2, __getgrnam_r (name=0x60400000c7e8 "1", -- |
From @iabynOn Mon, May 12, 2014 at 08:54:42PM -0400, George Greer wrote:
Ok, I'm fairly convinced now that its an ASan bug. I'll look into int getgrnam_r(const char *name, struct group *grp, there is only a match if the return value is zero, *and* *result is set to Where there is no match, but no error - such as looking up a non-existent Asan only uses the return value to decide whether to treat the fields of For some reason, on my system which just uses /etc/group, the _grent_struct I can't see any way to stop the smoke failures until ASan is fixed, unless -- |
From @greergaOn Tue, 13 May 2014, Dave Mitchell wrote:
Using "group: files" doesn't make a difference but stopping the Name -- |
From @iabynOn Wed, May 14, 2014 at 11:32:08PM -0400, George Greer wrote:
I reported it to the clang bugzilla, and they've (hopefully) fixed it -- |
From @greergaOn Sat, 17 May 2014, Dave Mitchell wrote:
Seems to be fixed, although AddressSanitizer seems to imply LeakSanitizer -- |
@iabyn - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#121831 (status was 'resolved')
Searchable as RT121831$
The text was updated successfully, but these errors were encountered: