Bug #127064 for PAR-Packer: Question about weird pp executable behavior

Fri Sep 07 10:58:42 2018 cqu [...] factset.com - Ticket created

Subject:	Question about weird pp executable behavior
Date:	Fri, 7 Sep 2018 14:48:40 +0000
To:	"bug-PAR-Packer [...] rt.cpan.org" <bug-PAR-Packer [...] rt.cpan.org>
From:	Chenchen Qu <cqu [...] factset.com>

Hi Roderich: We generate our production release with pp, and recently a new client ran into a weird issue. When they run the executable file, the cache directory was input as the first argument, for example When they do run.exe --setup the actual input was run.exe Sonntag\AppData\Local\Temp\par-4a616e20536f6e6e746167\cache-1535125512/run.exe --setup We are running pp with version PAR Packager, version 1.037 (PAR version 1.014), And the client was running the executable on Windows 7 with cmd. I think this might be some bad setup with their PATH variable, but I'm not 100% sure since I can't reproduce this on any VMs. Any suggestion is appreciated. Many thanks in advance, Chenchen

Mon Sep 10 01:42:41 2018 RSCHUPP [...] cpan.org - Taken

Mon Sep 10 02:04:01 2018 RSCHUPP [...] cpan.org - Correspondence added

Hi Chenchen, On 2018-09-07 10:58:42, cqu@factset.com wrote: Show quoted text

> When they run the executable file, the cache directory was input as > the first argument, for example > When they do run.exe --setup the actual input was run.exe > Sonntag\AppData\Local\Temp\par-4a616e20536f6e6e746167\cache- > 1535125512/run.exe --setup

Just curious: how did you find out? Did you something like pp -o run.exe -E "say qq[@ARGV]" and had the client run this run.exe? Show quoted text

> I think this might be some bad setup with their PATH variable, but I'm > not 100% sure since I can't reproduce this on any VMs. > Any suggestion is appreciated.

I can't think of something that would produce this effect... I would check the following environment variables in the client's environment whether they contain "unusual" characters (e.g. blanks): TMPDIR, TEMPDIR, TMP, TEMP and PATH. Also, are there any environment variables that start with PAR_? Note that the way how command line arguments are passed to the packed executable changed in PAR::Packer 1.038 and later. Could you prepare a test executable like the above packed with the latest PAR::Packer and have the client run it? Cheers, Roderich

Mon Sep 10 02:04:02 2018 The RT System itself - Status changed from 'new' to 'open'

Mon Sep 10 15:43:16 2018 cqu [...] factset.com - Correspondence added

Subject:	RE: [rt.cpan.org #127064] Question about weird pp executable behavior
Date:	Mon, 10 Sep 2018 19:12:43 +0000
To:	"bug-PAR-Packer [...] rt.cpan.org" <bug-PAR-Packer [...] rt.cpan.org>
From:	Chenchen Qu <cqu [...] factset.com>

Hi Roderich: 1. yes we save the @ARGV in our logs so we know exactly what the input is. 2. Weird thing is, I checked the client environment variable, there 's nothing special, both TEMP and TMP are defined as the local temp directory, nothing related with PAR_*. The only thing that raised my attention is the client also have perl installed on the instance, do you think that might cause the DynaLoader to load the wrong libraries and trigger an issue like this? I'm going to suggest the client to run our application on a clean vm, so this probably won't happen. Will update with the result. Thanks Chenchen Show quoted text

-----Original Message----- From: Roderich Schupp via RT <bug-PAR-Packer@rt.cpan.org> Sent: Monday, September 10, 2018 2:04 AM To: Chenchen Qu <cqu@factset.com> Subject: [rt.cpan.org #127064] Question about weird pp executable behavior <URL: https://rt.cpan.org/Ticket/Display.html?id=127064 > Hi Chenchen, On 2018-09-07 10:58:42, cqu@factset.com wrote:

> When they run the executable file, the cache directory was input as > the first argument, for example When they do run.exe --setup the > actual input was run.exe > Sonntag\AppData\Local\Temp\par-4a616e20536f6e6e746167\cache- > 1535125512/run.exe --setup

Just curious: how did you find out? Did you something like pp -o run.exe -E "say qq[@ARGV]" and had the client run this run.exe?

> I think this might be some bad setup with their PATH variable, but I'm > not 100% sure since I can't reproduce this on any VMs. > Any suggestion is appreciated.

I can't think of something that would produce this effect... I would check the following environment variables in the client's environment whether they contain "unusual" characters (e.g. blanks): TMPDIR, TEMPDIR, TMP, TEMP and PATH. Also, are there any environment variables that start with PAR_? Note that the way how command line arguments are passed to the packed executable changed in PAR::Packer 1.038 and later. Could you prepare a test executable like the above packed with the latest PAR::Packer and have the client run it? Cheers, Roderich

Thu Sep 13 05:28:59 2018 RSCHUPP [...] cpan.org - Correspondence added

Hi Chenchen, I was able to reproduce the problem with PAR::Packer 1.037 by running the packed executable with environment variables TEMP and TMP set to a path that contains blanks, e.g. set TEMP=C:\Users\SCHRO2~1\.cpanm\work\1536826253.8944\PAR-Packer-1.037\t m p The test script was pp -o foo.exe -E "use Data::Dumper; say 'ARGV = ', Dumper(\@ARGV);" and running this in above environment produces .\foo.exe 1 2 3 ARGV = $VAR1 = [ 'm', 'p\\par-536368526f32342d657874\\cache-688422ed2d95d8d78309df7ba393ecec060a8455/foo.exe', '1', '2', '3' ]; The same script packed with PAR::Packer 1.047 works correctly in this environment. Cheers, Roderich

Thu Sep 13 05:29:01 2018 RSCHUPP [...] cpan.org - Status changed from 'open' to 'resolved'

Thu Sep 13 10:04:27 2018 cqu [...] factset.com - Correspondence added

Subject:	RE: [rt.cpan.org #127064] Question about weird pp executable behavior
Date:	Thu, 13 Sep 2018 14:04:06 +0000
To:	"bug-PAR-Packer [...] rt.cpan.org" <bug-PAR-Packer [...] rt.cpan.org>, "par [...] perl.org" <par [...] perl.org>
From:	Chenchen Qu <cqu [...] factset.com>

Wow, thanks a lot Roderich, that would've taken me hours to debug that issue! And yes that 's exactly the cause, they do have a space in their TMP/TEMP variable. I will inform the client to set PAR_GLOBAL_TMPDIR and PAR_GLOBAL_TEMP with no space in it as a workaround for now, and will upgrade our library now. Really appreciate your help! Chenchen Show quoted text

-----Original Message----- From: Roderich Schupp via RT <bug-PAR-Packer@rt.cpan.org> Sent: Thursday, September 13, 2018 5:29 AM To: par@perl.org Subject: [rt.cpan.org #127064] Question about weird pp executable behavior Thu Sep 13 05:28:59 2018: Request 127064 was acted upon. Transaction: Correspondence added by RSCHUPP Queue: PAR-Packer Subject: Question about weird pp executable behavior Broken in: (no value) Severity: (no value) Owner: RSCHUPP Requestors: cqu@factset.com Status: open Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=127064 > Hi Chenchen, I was able to reproduce the problem with PAR::Packer 1.037 by running the packed executable with environment variables TEMP and TMP set to a path that contains blanks, e.g. set TEMP=C:\Users\SCHRO2~1\.cpanm\work\1536826253.8944\PAR-Packer-1.037\t m p The test script was pp -o foo.exe -E "use Data::Dumper; say 'ARGV = ', Dumper(\@ARGV);" and running this in above environment produces .\foo.exe 1 2 3 ARGV = $VAR1 = [ 'm', 'p\\par-536368526f32342d657874\\cache-688422ed2d95d8d78309df7ba393ecec060a8455/foo.exe', '1', '2', '3' ]; The same script packed with PAR::Packer 1.047 works correctly in this environment. Cheers, Roderich