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

This is a strange one... I embedded perl into a c program and all was working well. I used the example from O'Reilly's Programming Perl which seems to be the same as other examples I've seen on the web... 

int main( int argc, char** argv, char** env )
{
  PERL_SYS_INIT3( &argc, &argv, &env );
  my_perl = perl_alloc();
  perl_construct( my_perl );
  PL_exit_flags |= PERL_EXIT_DESTRUCT_END;
  perl_parse( my_perl, NULL, argc, argv, ( char** )NULL );
  perl_run( my_perl );
  perl_destruct( my_perl );
  perl_free( my_perl );
  PERL_SYS_TERM();
}

[download]

This WAS working!

I then installed other bits and bobs onto my Angstrom Linux Dist (Gumstix) such as Apache, PHP, FileZilla, Proftpd and all their endless dependencies and almost filled my 2GB micro SD bootable disk (about 90% full).

I then tried to run the embedded perl app (which was working) and I got a Segmentation Fault immediately and now get it every time I try to run the app.

I've 'make clean'd perl and re-installed from source but still the same. The strange thing is, perl seems to works fine, I can run %perl myPerlScript.pl no problems at all but when I run my embedded perl app I get Segmentation Fault. What could have changed???

I've not included too much detail here since to be honest I'm not sure what information will be of any use (remember, this WAS working).

I'm a perl and linux newbie.

Thanks for any help.

Replies are listed 'Best First'.
Re: perlembed segmentation fault
by aitap (Curate) on Jul 25, 2012 at 09:23 UTC
    Are you able to run this code somewhere else with segfault? Are you able to install gdb on the machine you are recieving segfault on and/or build perl and your application with debug symbols (gcc -g) enabled?
    Sorry if my advice was wrong.
[reply]
[d/l]

      Ok so I found the cause of the problem and I'm not sure if I should be embarrassed or not.

      I'm using proftpd on my target platform (angstrom) and FileZilla on my dev platform (ubuntu) so I can easily transfer the build outputs to target. I've been transferring executable files like this for weeks now with no problems at all.

      The transfer mode was set to auto, rather than explicit ascii or binary modes so I'm guessing this means it tries to work out which mode is best.
      Anyway, long story short, the auto mode decided ascii was the mode for the job and subsequently mangled my app behind my back. When set to explicit binary mode it started working again.

      Sorry for wasting everyone's time but I hope I can be forgiven for not first investigating something which has been working fine for weeks and not changed in any way.

      As a note to anyone who may experience something similar, ftp ascii mode can transfer executable files in some cases (if you're lucky as I was), but generally will mess up the file since it tries to convert \r\n's (windows-style) to \n's (unix-style).
      I think the only reason my transfers worked initially was because my binary files contained no \r\n bit patterns (as luck would have it, because it was a small file), then the inevitable happened and my binaries contained the pattern; regardless you should always use binary mode when transferring anything other than plain ascii text and I wouldn't rely on any auto mode; it's not difficult to manually choose ascii or binary.

[reply]

      You should be firstly very clear with why segmentation faults occurs. It can occur due to memory leaks, insufficient memory and other memory related issues.


      Try with freeing up some space.
      Prashant
[reply]

        I wish I knew how to be clear why the fault occured: The problem seems to occur in libperl.a and I stronlgly suspect it's when it calls perl_alloc().

        I'll initially rule out memory leaks since my test app currently does nothing other than instantiate and invoke perl.

        Insufficient memory strikes a chord. I currently have a 2GB micro SD card which was initially pretty empty when I successfully ran my app. Since then I installed loads of things and almost filled the SD card (I have about 200MB left), so I certainly have much less disk space now than I had before.

        My confusion is this: I am low on disk space, not ram. As far as I know perl_alloc() requires ram and not SD card space so I can't see how low SD card space would cause a problem.
        I ran 'top' to see if any other processes were hogging ram but almost all of the ram seems to be available.
        I do think you're onto something here with the hole "freeing up space" but I don't understand why. Besides, 200MB is still a lot of disk space for one app.

        I can't delete much on the SD card, plus I'm afraid of deleting the wrong thing. As a stab in the dark, I'll go get a 16GB card from the supermarket and try again. Is this what you had in mind or did you mean freeing up memory some other way?

[reply]

      I currently have no other platform to test the built app with so can't currently run anywhere else.

      Yes I can do the other things you suggested however with my platform (angstrom on arm7), these things take a very long time so I was hoping to resort to this level of diagnostics as a last resort. The fact that this was working makes me think the perl installation and embedded perl app are fine, it's the system which has changed somehow.

      Hold that thought ;-)

[reply]
        Do you have any segfault-related messages in the kernel log?
        Sorry if my advice was wrong.
[reply]

Back to Seekers of Perl Wisdom