Re: Smoke [ebcdic] v5.23.4-165-g4d9f9c0 FAIL(M) os/390 24.00 (2964/)
We still have the failure to build. My changes got rid of the unclosed #if errors, but that didn't fix the compilation failures. They look like this: Can't find 'boot_re' symbol in lib/auto/re/re.so at lib/re.pm line 88. This had been showing up in the logs besides the unclosed #if, but I figured that that error could have caused this one as well. But now, that one is gone, and this remains, so there is something else going wrong. Since my changes beyond blead being tested here differ only in minor tweaks from what had worked before, I have started to suspect that perhaps the problem wasn't my changes, but something that had happened in blead recently. Fortunately, you had just tested plain blead, and it worked: Smoke [blead] v5.23.4-94-g6cae08a PASS os/390 24.00 (2964/ I examined the changes in blead between this one that passed, and the first failure. There are only about a dozen commits. If you had git on your system, we could do an automatic bisect in fairly short order. The other option generally available is to do a manual bisect to find the real culprit. But in examining these dozen or so commits, almost half (5 of them) involved DynaLoader, and that is the module responsible for getting that 'boot_re' symbol. Looking at the other commits, they appear to me to be less likely to affect this. So suspicion naturally falls on those 5. So what I've done is to push a new branch to test, with the 5 reverted. I think it is fairly likely that it will not have the current failure. If I'm right, we can get their author to investigate further, and we've saved some effort by not having to do a blind manual bisect. If I'm wrong, then it's something else. So, if this branch still fails with the boot_re problem, we know its not the DynaLoader changes. Please then go ahead and test current blead without waiting for any new branch from me. If that works, then we know it's something I did, and I'll have to figure that out. If it doesn't work, then it's almost certainly one of those 7 or so other commits and we can revert some of those to find which one is at fault, and go on from there. On 11/18/2015 11:40 PM, Yaroslav Kuzmin wrote: Automated smoke report for branch ebcdic 5.23.5 patch 4d9f9c0de70352f49626dd8189478d5e490fea8c v5.23.4-165-g4d9f9c0 RS12: 2964 (2964/) onos/390 - 24.00 using c99 version smoketime 53 minutes 53 seconds (average 26 minutes 56 seconds) Summary: FAIL(M) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep v5.23.4-165-g4d9f9c0 Configuration (common) none --- - M - M - -Dusedl +- PERLIO = perlio -DDEBUGGING +--- PERLIO = stdio -DDEBUGGING +- PERLIO = perlio +--- PERLIO = stdio Locally applied patches: SMOKE4d9f9c0de70352f49626dd8189478d5e490fea8c Tests skipped on user request: # One test name on a line Compiler messages(os390): -- Report by Test::Smoke v1.6 running on perl 5.22.0 (Reporter v0.052 / Smoker v0.045) -- Regards, Yaroslav Kuzmin Developer C/C++ ,z/OS , Linux 3 Zhukovskiy Street · Miass, Chelyabinsk region 456318 · Russia Tel: +7.922.2.38.33.38 Email: ykuz...@rocketsoftware.com Web: www.rocketsoftware.com Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.
Re: Smoke [ebcdic] v5.23.4-165-g4d9f9c0 FAIL(M) os/390 24.00 (2964/)
On 11/19/2015 05:59 PM, Karl Williamson wrote: We still have the failure to build. My changes got rid of the unclosed #if errors, but that didn't fix the compilation failures. They look like this: Can't find 'boot_re' symbol in lib/auto/re/re.so at lib/re.pm line 88. This had been showing up in the logs besides the unclosed #if, but I figured that that error could have caused this one as well. But now, that one is gone, and this remains, so there is something else going wrong. Since my changes beyond blead being tested here differ only in minor tweaks from what had worked before, I have started to suspect that perhaps the problem wasn't my changes, but something that had happened in blead recently. Fortunately, you had just tested plain blead, and it worked: Smoke [blead] v5.23.4-94-g6cae08a PASS os/390 24.00 (2964/ I examined the changes in blead between this one that passed, and the first failure. There are only about a dozen commits. If you had git on your system, we could do an automatic bisect in fairly short order. The other option generally available is to do a manual bisect to find the real culprit. But in examining these dozen or so commits, almost half (5 of them) involved DynaLoader, and that is the module responsible for getting that 'boot_re' symbol. Looking at the other commits, they appear to me to be less likely to affect this. So suspicion naturally falls on those 5. So what I've done is to push a new branch to test, with the 5 reverted. I think it is fairly likely that it will not have the current failure. If I'm right, we can get their author to investigate further, and we've saved some effort by not having to do a blind manual bisect. If I'm wrong, then it's something else. So, if this branch still fails with the boot_re problem, we know its not the DynaLoader changes. Please then go ahead and test current blead without waiting for any new branch from me. If that works, then we know it's something I did, and I'll have to figure that out. If it doesn't work, then it's almost certainly one of those 7 or so other commits and we can revert some of those to find which one is at fault, and go on from there. I also got some advice from bulk88 in tracking this down which I'm passing on as-is: "look at re.c on the os390 build, is XS_EXTERNAL(boot_re) there? next step is search the .o files for the symbol then nm or objdump the .so the preprocessed .i file between re.c and re.o is another place to check the question is, where in the build process did the symbol disappear? xsubpp could have forgotten to write a boot xsub the boot xsub might be disabled with CPP defines the def file (if platform appropriate, aka Win32) might eb screwed up, especially if the export list was changed from makefile.PL (it doesn't look to be that way from re/makefile.pl) Can't find 'boot_re' symbol in lib/auto/re/re.so at lib/re.pm line 88. Compilation failed in require at lib/Text/Wrap.pm line 58. BEGIN failed--compilation aborted at lib/Text/Wrap.pm line 58. Compilation failed in require at pod/buildtoc line 7. BEGIN failed--compilation aborted at pod/buildtoc line 7. make: *** [pod/perltoc.pod] Error 255 Unable to make anything but miniperl in this configuration that could also be a @INC problem, or a PERL_CORE env var problem that leads to a messe dup @INC if the .so was from a different perl build or a different CC, name mangling, which is invisible on a superifical level, might be different internally, so "boot_re" != "boot_re" missing symbol errors are fixed by analyzing each step of .xs -> .so/.dll -> .so/.dll memory mapped into perl process freezing the process (as simple as block on STDIN), then getting a dump of the VM allocations in the process, which will list every .so/.dll in the process is a standard thing I do pwd when starting perl core .t and .pl files is usually important, many .t and .pl have if( -d 't') {chdir('..');} so fi they are started with the wrong pwd they escape the source tree and pick up system perls and system perl @INCs" On 11/18/2015 11:40 PM, Yaroslav Kuzmin wrote: Automated smoke report for branch ebcdic 5.23.5 patch 4d9f9c0de70352f49626dd8189478d5e490fea8c v5.23.4-165-g4d9f9c0 RS12: 2964 (2964/) onos/390 - 24.00 using c99 version smoketime 53 minutes 53 seconds (average 26 minutes 56 seconds) Summary: FAIL(M) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep v5.23.4-165-g4d9f9c0 Configuration (common) none --- - M - M - -Dusedl +- PERLIO = perlio -DDEBUGGING +--- PERLIO = stdio -DDEBUGGING +- PERLIO = perlio +--- PERLIO = stdio Locally applied
Smoke [ebcdic] v5.23.4-165-g4d9f9c0 FAIL(M) os/390 24.00 (2964/)
Automated smoke report for branch ebcdic 5.23.5 patch 4d9f9c0de70352f49626dd8189478d5e490fea8c v5.23.4-165-g4d9f9c0 RS12: 2964 (2964/) onos/390 - 24.00 using c99 version smoketime 53 minutes 53 seconds (average 26 minutes 56 seconds) Summary: FAIL(M) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep v5.23.4-165-g4d9f9c0 Configuration (common) none --- - M - M - -Dusedl > > > +- PERLIO = perlio -DDEBUGGING > > +--- PERLIO = stdio -DDEBUGGING > +- PERLIO = perlio +--- PERLIO = stdio Locally applied patches: SMOKE4d9f9c0de70352f49626dd8189478d5e490fea8c Tests skipped on user request: # One test name on a line Compiler messages(os390): -- Report by Test::Smoke v1.6 running on perl 5.22.0 (Reporter v0.052 / Smoker v0.045) -- Regards, Yaroslav Kuzmin Developer C/C++ ,z/OS , Linux 3 Zhukovskiy Street · Miass, Chelyabinsk region 456318 · Russia Tel: +7.922.2.38.33.38 Email: ykuz...@rocketsoftware.com Web: www.rocketsoftware.com Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. log4d9f9c0de70352f49626dd8189478d5e490fea8c.log.gz Description: log4d9f9c0de70352f49626dd8189478d5e490fea8c.log.gz