indirect.pm fails assertions with threaded perl #16893
Comments
From @shlomifindirect.pm-asserts-fail.md :Author: Shlomi Fish Hi all! After building perl using: ``` on bleadperl: ``` inline.h: Improve comment running all tests successfully and installing. Then I get: ``` chmod 755 blib/arch/auto/indirect/indirect.so Test Summary Report t/40-threads.t (Wstat: 134 Tests: 0 Failed: 0) I am on mageia v7 x86-64 ( https://en.wikipedia.org/wiki/Mageia ). ``` Flags: Site configuration information for perl 5.29.9: Configured by shlomif at Sat Mar 16 15:07:03 IST 2019. Summary of my perl5 (revision 5 version 29 subversion 9) configuration: @INC for perl 5.29.9: /home/shlomif/apps/perl/bleadperl-debug/lib/site_perl/5.29.9/x86_64-linux-thread-multi /home/shlomif/apps/perl/bleadperl-debug/lib/5.29.9/x86_64-linux-thread-multi Environment for perl 5.29.9: PATH=/home/shlomif/Download/unpack/perl/p5/emcc-build/perl-emcc-build:/home/shlomif/bin:/usr/local/bin:/usr/bin:/usr/local/games:/usr/games:/usr/lib64/qt4/bin:/usr/lib64/qt5/bin:/bin ``` -- Buddha has the Chuck Norris nature. Please reply to list if it's a mailing list post - http://shlom.in/reply . |
From @jkeenanOn Sat, 16 Mar 2019 14:51:14 GMT, shlomif@gmail.com wrote:
My research so far indicates that it is the combination of -Duseithreads AND -DDEBUGGING that causes the failures in two tests in indirect's test suite. I.e., I do *not* get the failures when I build with threads or with debugging individually. This also appears to be the case with these two failures reported by Andreas: http://www.cpantesters.org/cpan/report/6df6fa7e-3840-11e9-99ca-ba6e2b878bbe http://www.cpantesters.org/cpan/report/f3ffdba6-3852-11e9-a75d-ac272b878bbe Can you confirm that it is the combination of these two configure options that generates the failures? Thank you very much. -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @jkeenanOn Sun, 17 Mar 2019 00:07:58 GMT, jkeenan wrote:
Building with threads and debugging, I have (I think) narrowed this down to breakage between v5.27.3 and v5.27.4. However, 'Porting/bisect.pl' is not DWIMming for me -- at least not when called with this pattern of arguments: ##### The program terminates at the start commit but, even if I know that at the start tag 'indirect' gets installed, the program reports that it exits 256 instead of 0 and the bisection program terminates. Anyone have suggestions for better bisecting? Thank you very much. |
From @jkeenanOn Sun, 17 Mar 2019 02:00:00 GMT, jkeenan wrote:
Manual bisection points to this commit: ##### (perl #131746) avoid undefined behaviour in Copy() etc These functions depend on C library functions which have undefined behaviour when passed NULL pointers, even when passed a zero 'n' value. Some compilers use this information, ie. assume the pointers are non-NULL when optimizing any following code, so we do need to prevent such unguarded calls. My initial thought was to add conditionals to each macro to skip the call to the library function when n is zero, but this adds a cost to every use of these macros, even when the n value is always true. So instead I added asserts() which will give us a much more visible indicator of such broken code and revealed the pp_caller and Glob.xs issues also patched here. Tony, can you take a look? Thank you very much. -- |
From @jkeenanOn Sun, 17 Mar 2019 02:40:36 GMT, jkeenan wrote:
Andreas reported this problem upstream. See:
-- |
From @shlomifHi, On Sun, Mar 17, 2019 at 2:07 AM James E Keenan via RT <
Indeed. With either of these options removed - "cpan -i indirect" works.
-- Buddha has the Chuck Norris nature. Please reply to list if it's a mailing list post - http://shlom.in/reply . |
From @khwilliamsonOn 3/17/19 8:38 AM, Shlomi Fish wrote:
Note that without -DDEBUGGING, asserts are no-ops, so of course it won't
|
From @tonycozOn Sat, 16 Mar 2019 07:51:14 -0700, shlomif@gmail.com wrote:
This is a bug in indirect. Copy() is built on top of memcpy(), and it causes undefined behaviour if you supply a NULL pointer to memcpy() even if no data is being copied. When I was working on #131746 I had two possible solutions: a) add conditionals to the Copy() etc macros so they're safe if "n" is zero. b) assert() that the pointers are non-NULL The problem with a) is that every call to the macros pay the cost, even code that correctly only calls these macros with non-NULL pointers. It also means that there's no indication to CPAN modules that use these macros that they're doing something undefined in older perls, since older perls wouldn't have the conditionals, and might still be supplying NULL pointers, resulting in undefined behaviour on older perls. So I went with b) so rather than hiding undefined behaviour bugs, a -DDEBUGGING build will scream about them. Tony |
|
This was fixed in indirect 0.39, released 9 months ago, so I'm closing this ticket. From an user's perspective, it wasn't really clear that Copy() had the same shortcomings as memcpy() : perlapi says "The XSUB-writer's interface to the C "memcpy" function", which is quite vague, and perlguts says nothing. This change was probably the best theoretical solution, but it did cause breakage where it could have fixed user land code instead. I still think it's a missed opportunity, as the NULL check would have been optimized away by any sane compiler in most cases. |
Migrated from rt.perl.org#133938 (status was 'open')
Searchable as RT133938$
The text was updated successfully, but these errors were encountered: