Skip to content
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

t/cleanup.t fails on freebsd 13 #37

Open
eserte opened this issue Jan 26, 2020 · 6 comments
Open

t/cleanup.t fails on freebsd 13 #37

eserte opened this issue Jan 26, 2020 · 6 comments

Comments

@eserte
Copy link
Contributor

@eserte eserte commented Jan 26, 2020

On my freebsd 13 smoker t/cleanup.t fails:

#   Failed test 'exception did not cause segfault'
#   at t/cleanup.t line 14.
#          got: '10'
#     expected: '10752'
# Looks like you failed 1 test of 1.
t/cleanup.t ................................ 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 

A full fail report:
http://www.cpantesters.org/cpan/report/1bfbc8a6-3daf-11ea-a4ca-ea331f24ea8f

There are no problems on my other freebsd systems (12, 11, 10, 9).

@FGasper

This comment has been minimized.

Copy link
Contributor

@FGasper FGasper commented Feb 1, 2020

It appears to be SIGBUS. (https://www.freebsd.org/cgi/man.cgi?query=signal&apropos=0&sektion=0&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html)

Curiously, the test seems to fail sometimes with $? == 10 and other times with $? == 138, though I think the only difference is that 138 means a core dump happened. @eserte, is it possible to make that core dump available?

I created this test recently as part of the fix for the segfault issue I’d found. If it’s a problem I could make it skip outside author or release testing.

@FGasper

This comment has been minimized.

Copy link
Contributor

@FGasper FGasper commented Feb 1, 2020

I unfortunately don’t have access to a FreeBSD machine myself. It would be useful to know if the recent segfault fix is what produces the breakage here.

I tried to repro on NetBSD, but the test passes there.

@eserte

This comment has been minimized.

Copy link
Contributor Author

@eserte eserte commented Feb 1, 2020

Here's a backtrace:

(gdb) bt
#0  0x0000000800bb481d in perl_curl_multi_magic_free () from /usr/home/cpansand/.cpan/build/2020020108/Net-Curl-0.43-0/blib/arch/auto/Net/Curl/Curl.so
#1  0x0000000000456200 in S_mg_free_struct ()
#2  0x00000000004561ab in Perl_mg_free ()
#3  0x000000000047f667 in Perl_sv_clear ()
#4  0x0000000000480331 in Perl_sv_free2 ()
#5  0x000000000047511f in Perl_sv_clean_objs ()
#6  0x00000000003da35a in perl_destruct ()
#7  0x00000000003bb3af in main ()

Is this helpful, or should I build a debugging perl for more information?

@FGasper

This comment has been minimized.

Copy link
Contributor

@FGasper FGasper commented Feb 1, 2020

I think this is actually showing a different bug altogether. Will try to look later.

@FGasper

This comment has been minimized.

Copy link
Contributor

@FGasper FGasper commented Feb 1, 2020

I’ve got a VM up that shows this problem. The same failure happens if I bring this test in to v0.42, so at least v0.43 appears not to have regressed.

@FGasper

This comment has been minimized.

Copy link
Contributor

@FGasper FGasper commented Feb 1, 2020

I think I found the problem. The XS multi struct’s “easies” list isn’t updated as part of the cleanup of the easy. So when multi is cleaned up it tries to access already-freed stuff.

PR forthcoming.

FGasper added a commit to FGasper/perl-Net-Curl that referenced this issue Feb 2, 2020
Issue sparky#37: This caused SIGBUS on FreeBSD 13 and OpenBSD 6.6 in certain
Perl garbage-collection scenarios.

Testing confirmed this fix in FreeBSD 13 and noted no regressions in
FreeBSD, macOS, Linux, and NetBSD.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.