http://www.perlmonks.org?node_id=1213554

stevieb has asked for the wisdom of the Perl Monks concerning the following question:

Hello fellow Monks,

I am experiencing an issue with some C/XS I'm trying to get working. I will explain what I'm trying to do, how I perceive what the code is actually doing and a bit about what's happening. I'll then show the Inline::C code, the output, some gdb debugging output. Unfortunately, unless you have a Raspberry Pi, there's no way you can repro this successfully.

What I'm trying to do:

I have an interrupt routine for a GPIO pin on the Pi. This interrupt routine (ISR) is spun off into a separate C++ thread, and to facilitate the ability for the user to use a Perl subroutine as the callback/interrupt handler, I'm trying to pass in a code reference, and have the C/XS execute that sent-in-as-a-param code ref.

What is the code doing?:

I set up a function in main called cref_handler(). I then initialize the RPi, configure the appropriate GPIO pin, then set the interrupt on that pin, passing in a reference to the mentioned cref_handler() routine. The interrupt handler (the code the coderef points to) is to run any time the specified pin goes LOW (ie. 0 volts). Both the interrupt setup and the actual interrupt handler that executes the code in the coderef is written in C and passed along to an external library that dumps the ISR into its own thread.

What the hell is happening?:

The callback code simply prints to STDOUT. Once the script is run, I may get a few printouts when shorting (ie. turning LOW the pin), sometimes I don't. In all cases, it eventually leads to a SEGFAULT. Sometimes after a microsecond, sometimes after a second or two.

I'm not an expert C coder by any stretch, so I believe what may be happening is that the threaded interrupt code isn't handling the global C variables I've set up, or perhaps it's the way I'm using some of Perl's internals wrong (eg: PerlInterpreter, PERL_SET_CONTEXT etc), or the way the interruptHandlerCref() XS code is laid out.

Summary:

I'd greatly appreciate it if those experienced in these XS/C matters could have a look and see what I'm doing wrong here, if its possible without having to actually run the code (I truly apologize for that inability). I'm thinking it's my inexperience with C, or misunderstanding how the whole background threads thing is handled here.

Code:

use warnings; use strict; use RPi::Const qw(:all); use Inline ('C' => 'DATA' => libs => '-lwiringPi -lrt -lwiringPiDev -l +pthread'); my $continue = 1; $SIG{INT} = sub { $continue = 0; }; sub cref_handler { print "cref handler\n"; } my $cref = \&cref_handler; init(); pin_mode(3, INPUT); setInterruptCref(3, EDGE_FALLING, $cref); my $running; while ($continue){ print "running\n" if ! $running; $running = 1; } __DATA__ __C__ #include <wiringPi.h> #include <stdio.h> void init (){ wiringPiSetupGpio(); } PerlInterpreter* mine; SV* perl_callback_cref; void interruptHandlerCref(){ PERL_SET_CONTEXT(mine); dSP; ENTER; SAVETMPS; PUSHMARK(SP); PUTBACK; call_sv(perl_callback_cref, G_DISCARD|G_NOARGS); FREETMPS; LEAVE; } int setInterruptCref(int pin, int edge, SV* callback){ mine = Perl_get_context(); perl_callback_cref = callback; int interrupt = wiringPiISR(pin, edge, &interruptHandlerCref); return interrupt; } void pin_mode (int pin, int mode){ pinMode(pin, mode); }

Output:

running cref handler cref handler cref handler running dler running dler Segmentation fault

I am perplexed as to how the running line is printed numerous times, given that it should only print once, at the onset after everything else is done. This is what leads me to believe something is going very wacky with the threading somehow...

Debug output (snipped for brevity):

$ gdb perl GNU gdb (Raspbian 7.12-6) 7.12.0.20161007-git (gdb) r int.pl [New Thread 0x76af7470 (LWP 26138)] running cref handler Thread 1 "perl" received signal SIGSEGV, Segmentation fault. 0x000c09ec in Perl_pp_and () (gdb) bt #0 0x000c09ec in Perl_pp_and () #1 0x000c0434 in Perl_runops_standard () #2 0x000500a4 in perl_run () #3 0x0002ab50 in main ()

The backtraces are consistently different, fwiw, but mostly they are relatively similar. I can repro several times if necessary if it'll help.

Cheers,

-stevieb