Re^2: XS: exposing C++ library constant as package variable

I tried just using GV_ADD, but it gave me a segfault:

==44885== Invalid write of size 8
==44885==    at 0x6BA4D37: boot_MyModule (mymodule.xs:113)
==44885==    by 0x4CB944F: Perl_pp_entersub (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4CB7785: Perl_runops_standard (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4C59496: Perl_call_sv (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4C5999C: Perl_call_list (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4C45138: S_process_special_blocks (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4C533EC: Perl_newATTRSUB (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4C53AA2: Perl_utilize (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4C82FFF: Perl_yyparse (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4CF0918: S_doeval (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4CF143A: Perl_pp_entereval (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4CB7785: Perl_runops_standard (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
==44885==
==44885==
==44885== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==44885==  Access not within mapped region at address 0x18
==44885==    at 0x6BA4D37: boot_MyModule (mymodule.xs:113)
==44885==    by 0x4CB944F: Perl_pp_entersub (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4CB7785: Perl_runops_standard (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4C59496: Perl_call_sv (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4C5999C: Perl_call_list (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4C45138: S_process_special_blocks (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4C533EC: Perl_newATTRSUB (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4C53AA2: Perl_utilize (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4C82FFF: Perl_yyparse (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4CF0918: S_doeval (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4CF143A: Perl_pp_entereval (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==    by 0x4CB7785: Perl_runops_standard (in /export/my_company/Linux_RHEL6_x86_64/lang/perl/5.12/lib/5.12.5/x86_64-linux-thread-multi/CORE/libperl.so)
==44885==  If you believe this happened as a result of a stack
==44885==  overflow in your program's main thread (unlikely but
==44885==  possible), you can try to increase the size of the
==44885==  main thread stack using the --main-stacksize= flag.
==44885==  The main thread stack size used in this run was 10485760.

mymodule.xs:113 is where I'm calling SvIV_set. The same thing happens if I leave $CONSTANT_NAME in the use vars statement, but don't initialize it in BEGIN.

Comment on Re^2: XS: exposing C++ library constant as package variable

Replies are listed 'Best First'.
Re^3: XS: exposing C++ library constant as package variable by BrowserUk (Patriarch) on Oct 08, 2015 at 15:11 UTC
Address 0x18 is not stack'd, malloc'd or (recently) free'd That suggests that get_sv() is returning an invalid SV; which it shouldn't, if the docs are to be believed: `get_sv Returns the SV of the specified Perl scalar. flags are passed to gv_fe +tchpv. If GV_ADD is set and the Perl variable does not exist then it +will be created. If flags is zero and the variable does not exist the +n NULL is returned. NOTE: the perl_ form of this function is deprecated. SV get_sv(const char *name, I32 flags)` [download] I think your only course of action (other than sticking with the way you have that works) is to write a minimal testcase and raise a perlbug. P5p will either: correct the code; or correct my interpretation of the docs. Of course, any resolution will take time, so you'll probably need to stick with what you originally had for now anyway. Sorry for the bum steer. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :) In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l]
Re^4: XS: exposing C++ library constant as package variable ( sv_setiv , SvIV_set ) by Anonymous Monk on Oct 08, 2015 at 22:42 UTC
That suggests that get_sv() is returning an invalid SV; which it shouldn't, if the docs are to be believed:* :) nope, its the call to SvIV_set thats causing it, solution i use is sv_setiv `SV* const_sv = get_sv( "Soivro::SOIVRO", GV_ADD ); sv_setiv( const_sv, FILENAME_MAX ); SvREADONLY_on( const_sv );` [download]	[reply] [d/l]
Re^5: XS: exposing C++ library constant as package variable ( sv_setiv , SvIV_set ) by ikegami (Patriarch) on Oct 09, 2015 at 05:27 UTC
It was crashing because you forgot to upgrade the scalar to one that has an IV slot before trying to change the IV slot. `sv_setiv` works because it performs the upgrade.	[reply] [d/l]
Re^6: XS: exposing C++ library constant as package variable ( sv_setiv , SvIV_set ) by wisnij (Novice) on Oct 14, 2015 at 16:19 UTC
Re^7: XS: exposing C++ library constant as package variable ( sv_setiv , SvIV_set ) by Anonymous Monk on Oct 15, 2015 at 00:36 UTC
Re^5: XS: exposing C++ library constant as package variable ( sv_setiv , SvIV_set ) by BrowserUk (Patriarch) on Oct 08, 2015 at 23:44 UTC
Thanks. Though it might have been better to address the information to the OP. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :) In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^6: XS: exposing C++ library constant as package variable ( sv_setiv , SvIV_set ) by Anonymous Monk on Oct 08, 2015 at 23:51 UTC
Re^7: XS: exposing C++ library constant as package variable ( sv_setiv , SvIV_set ) by BrowserUk (Patriarch) on Oct 09, 2015 at 00:12 UTC
Re^4: XS: exposing C++ library constant as package variable by wisnij (Novice) on Oct 08, 2015 at 18:00 UTC
Fair enough. Hopefully in the near future I'll have some time to look into this more deeply. For now, as long as my original approach looks valid (if perhaps not stylistically optimal) I'll stick with that. Thanks for the input.	[reply]