AdityaKoshti
commented
1 week ago Hi @bdbaddog and @mwichmann,
I am currently in the process of migrating my source code from SCons version 2.3.0 to 4.5.2, but I am still encountering this error. I was wondering if this issue has been resolved in any of the latest versions that are compatible with Python 3.12?
This issue was originally created at: 2015-03-14 18:52:42. This issue was reported by:
danmcnaul.Before I describe the problem, I need to point out that I tried to provide you with a complete test suite to recreate this issue. The problem I ran into is that the bug occurs while using a licensed product that I can not supply with this "BUG REPORT". I also have to be careful what I disclose due to copy-righted material. I'm sorry.
This bug occurs in scons2.3.4. It does NOT occur in scons2.3.0. I am now using scons2.3.0 in my builds, so I am NOT stuck. I did not try 2.3.1, 2.3.2, or 2.3.3. I can try to do that if you think it will help.
My build executes csfdc (DataComplete from CSF) from a Builder I wrote and placed in my SConstruct script. As you can see from the build output, that generates a very long
$TARGETlist. The libraries that are built following that step fail to build with theAttributeError. It is circumstantial evidence, but it appears the long csfdc$TARGEThas something to do with the subsequent errors. (memory corruption??)Here is the SCONS 2.3.4 build report.
Here is the SCONS 2.3.0 build report. =>===================================
=========== END OF SCONS 2.3.0 ==========================
Hi Dan,
I understand that there are copyright issues involved here, but would you be able to show us the source for the Builder that you wrote (anonymized, where required)? It will be difficult to hunt this down without having a clear picture of how you try to attack things. If required we could probably set something up, where you send it to a single person which signs a non-disclosure agreement. Do you think that would be possible?
Regards,
Dirk
Just as an additional question, coming to my head right now: are you by any chance using the
-j xoption when the failure happens? Please try in simple serial mode and ensure that the error doesn't occur. Also leave out any "hack options" like--implicit-deps-unchangedfor making the build faster.Created an attachment (id=953) A Test Suite to quickly recreate the issue
Let's see if I can figure out how to attach this "Test Suite". I build a test suite for you to play with (Linux). Untar it and read the README. If you need more info let me know.
The README tells you this, but don't mess with the contents of "official". That should never change. Do your builds in scon2.3.4 and scon2.3.0.
OK - I regression tested 2.3.1, 2.3.2, and 2.3.3.
Issue #2998 exists in 2.3.1 and 2.3.3.
In 2.3.2, scons didn't like something about my SConscripts. It bailed out during "Reading SConscript files ...." and didn't get to the build.
Of course, we know 2.3.0 works correctly.
This information may be helpful in figuring out what's going on.
Thanks a lot for all the infos you provided, and for your well prepared issue report in general.
So far, I had only time for a quick first glance...but what I noticed is that your "csfdc" Builder doesn't seem to have a custom Emitter installed (see https://www.scons.org/wiki/ToolsForFools for an example). Are you aware of this? I'll have to investigate this further, but it might be the (or, one) reason for your troubles.
You could try to check the dependency graph on your side with the "--tree=all" option. It should show that the source files in question depend on the csfdc Build step. If they don't, things may go wrong at any time. It might actually be a pure coincidence that your build works under certain SCons versions, or not.
I'll keep you posted...
A Test Suite to quickly recreate the issue