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.
In reply to Re^2: perlembed segmentation fault
by 4Xsake
in thread perlembed segmentation fault
by 4Xsake
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |