Re: PP generates some duff code with multithreading enabled
Did the same with no fault here, build 809, XP, and the latest snap of PAR compiled with VC 6. Are you self compiling PAR or using the binary download? Downloading the binaries of PAR. Has been like this for the last few versions though. I do have VC .Net here. I will try and compile PAR myself with that and see if anything changes Thanks Ed W
Re: PP generates some duff code with multithreading enabled
Thanks Alan, You are right that something strange is going on here. I ran the aa.exe that the.noonings created, and it runs fine on my machine. Coupled with what you say below that my exe is crashing on your machine suggests something strange going on with my par install. The original install was done after perl 5.8.2 was installed, and was either done using the precompiled download, or slightly possibly from the activestate download (I think the former though). Now that I rebuilt 0.80 from source it doesn't crash, on my little test program, but more complicated stuff is failing, so I think I need to re-install all my perl modules (wxwindows, etc). Will report back after that. Thanks everyone Ed W I see several things, but I can't put them together yet. Your a.exe creates a temp cache dir with a short MD5 hash name, while mine creates a long SHA1 cache name. That implies that yours is created in the embedded par.pl, when mine is done in the static.c header. Also, mine extracts stuff to an inc subdir of the cache, while yours does not. If I run yours from the command line, it crashes the first time and every time. If I double click it, it runs the first time and then crashes every time after that. If I delete the cache and run it, it runs the first time and then crashes afterwards. If I rename my c:\perl directory to hide it, your a.exe runs OK everytime ?!? The only way your a.exe can find my perl install is by the copy of Config.pm in a.exe. Both of our Config.pm's point to c:\perl. There must be some conflict between the stuff in your PAR binary and the perl install we both have for 5.8.3. You may find that you have no problem running your application on a machine that doesn't have perl installed (or at least not in c:\perl). Or your problem may go away if you download the snapshot and compile yourself. Alan Stewart
Re: PP generates some duff code with multithreading enabled
Hmm, OK, well I have rebuild PAR 0.80 from source, and re-installed wxperl and now everything is working fine... I'm fairly sure that if I re-installed the binary version of par then this would re-occur though. Any ideas why? Thanks all. This is a major improvement for me. I still have quite a few bugs, but not sure how best to announce them, since I don't have good reproducable cases for most of them. For example, I manually build an intermediate par file, then remove the Wx dll's, then build the exe. However, if the Wx dlls aren't then in the patch when I run the final exe, something goes mad, consumes all available ram in the machine until it falls over in a heap... If I build the exe without --gui then the last thing I see on the console is the message about being unable to locate loadable object for module Wx in To be fair this may not be a par issue at all... I didn't think to check what happens normally if I just delete the dll's Ooops, will go and do that next! Thanks again Ed W
PP generates some duff code with multithreading enabled
Please try the following snippet through pp. It executes fine, but crashes when the app exits (at least on win32, havent tried linux yet). I would be really grateful if someone could help debug this - it's the last major bug standing in the way of packaging my little email app with par. #!/usr/bin/perl use threads; use threads::shared; print Cras\n; ## fails to exit cleanly after this... Thanks for any help. Ed W P.S. Autrijus, I will try to check it out myself, but in the latest pre-release did you check in Alan Stewarts changes to fix the --icon problem where it increases the file size? I have just been retesting his version and it does seem to work fine for me? Thanks
Interesting crash on Windows (at least..)
Hi, I have discovered two bits of source which cause pp to generate an executable which crashes with the usual windows protection error when the app exits. The first and easy way (ie, that I can work around) is to generate a module.pm file, and start it with #!/bin/perl, then include it in a main .pl file. There doesn't seem to need to be anything in the module file, just the simple fact of starting it with the shebang line causes the resultant pp exe to crash when it exits. Obviously module files shouldn't really start with a shebang so this is easy to work around The second one is giving me real grief though, and this is to add a use threads; line to the main app. Everything works fine, but the app crashes when it exits.. I really need to use perl threads in this app, so does anyone have any suggestions on how to work around this...? Versions: Perl 5.8.2 build 808 (also didn't work on perl 5.8.0) Win XP sp1 par 0.80 (I think?), however, this has been a problem for quite a while back now (just haven't had time to debug it) Any suggestions on how to make threads work with par...? Is this actually reproducable for anyone else...? (I don't actually need to use any code to cause the problem, simply include the threads modules) Thanks Ed W
Re: PAR - WIN32 Client/Server application using fork() problem
Oh and PAR seem to work fine on other standard Perl scripts I've used. But must admit I've not tried compiling a script with fork() on a WIN32 system before. I've never found fork to work reliably at all on Win32. See the perlport notes. Perhaps things are better with 5.8 though? Consider just rewriting it to use a select loop. It was much easier for my app that way. Good luck
