[Scons-users] Determining source of scons crash

Luke Robison lukerobison at gmail.com
Fri Apr 24 16:54:31 EDT 2020 

Correct.  For example, I'm sure with C code you could make a StaticLibrary
and a SharedLibrary, those would require .o and .os files respectively
(compiled from the same source code).  The problem is unique to the fact
that gfortran (and ifort, and most other fortran compilers) emit a .mod
file each time they compile a source file which includes a "module"
statement, and while the .o/.os files deconflict, the .mod files would be
named the same.

To make matters a little worse: My experience is that ifort produces a
unique .mod file each time you re-compile the same source (I suspect they
have a timestamp in there for some reason -- this forces scons to rebuild
more than necessary!).  Luckily gfortran re-produces the exact same if you
re-compile the same source.


On Fri, Apr 24, 2020 at 3:22 PM Bill Deegan <bill at baddogconsulting.com>
wrote:

> Hmm..
> so .o and.os but they're both generating the same .mod filename?
>
> On Fri, Apr 24, 2020 at 1:21 PM Bill Deegan <bill at baddogconsulting.com>
> wrote:
>
>> So you're building both an object and a shared object from the same
>> source?
>> Without specifying a target to create a different named file?
>>
>>
>> On Fri, Apr 24, 2020 at 12:26 PM Luke Robison <lukerobison at gmail.com>
>> wrote:
>>
>>> Minor Correction: In my case my library was making a StaticLibrary and I
>>> was calling env.SharedObject manually.
>>>
>>> Additionally, on Linux you can remove the Object() builds and replace
>>> them with both SharedLibrary and StaticLibrary, and get the same error.
>>> For some reason windows/MSYS didn't seem to crash on that configuration.
>>>
>>> On Fri, Apr 24, 2020 at 2:20 PM Luke Robison <lukerobison at gmail.com>
>>> wrote:
>>>
>>>> It seems the problem was that I was making my Library as:
>>>> env.SharedLibrary( src_glob ), but that I had also called env.SharedObject(
>>>> src_glob ).  it seems the SharedLibrary was implicitly building .o files
>>>> and I had requested .os files as well, and probably generating those
>>>> compiled headers (.mod files) twice.  When I changed to calling env.Objects
>>>> rather than env.SharedObjects (or, turns out I wasn't using them anyways,
>>>> get rid of the call entirely) then the build is happy.
>>>>
>>>> Here is minimum to reproduce:
>>>>
>>>> test1.f90
>>>> module mod1
>>>>     integer :: mod1_int
>>>> end module
>>>>
>>>> Sconstruct
>>>> env = Environment()
>>>> src = ['test1.f90']
>>>> env.Object(src)
>>>> env.SharedObject(src)
>>>>
>>>> Execution:
>>>> $ scons
>>>> scons: Reading SConscript files ...
>>>> scons: done reading SConscript files.
>>>> scons: Building targets ...
>>>> gfortran -o test1.os -c test1.f90
>>>> gfortran -o test1.o -c test1.f90
>>>> scons: done building targets.
>>>> AttributeError: 'NoneType' object has no attribute 'get_build_env':
>>>>   File "/usr/lib/python3.7/site-packages/SCons/Script/Main.py", line
>>>> 1381:
>>>>     _exec_main(parser, values)
>>>>   File "/usr/lib/python3.7/site-packages/SCons/Script/Main.py", line
>>>> 1344:
>>>>     _main(parser)
>>>>   File "/usr/lib/python3.7/site-packages/SCons/Script/Main.py", line
>>>> 1119:
>>>>     nodes = _build_targets(fs, options, targets, target_top)
>>>>   File "/usr/lib/python3.7/site-packages/SCons/Script/Main.py", line
>>>> 1318:
>>>>     jobs.run(postfunc = jobs_postfunc)
>>>>   File "/usr/lib/python3.7/site-packages/SCons/Job.py", line 111:
>>>>     self.job.start()
>>>>   File "/usr/lib/python3.7/site-packages/SCons/Job.py", line 216:
>>>>     task.executed()
>>>>   File "/usr/lib/python3.7/site-packages/SCons/Script/Main.py", line
>>>> 256:
>>>>     SCons.Taskmaster.OutOfDateTask.executed(self)
>>>>   File "/usr/lib/python3.7/site-packages/SCons/Taskmaster.py", line 312:
>>>>     t.push_to_cache()
>>>>   File "/usr/lib/python3.7/site-packages/SCons/Node/FS.py", line 2967:
>>>>     self.get_build_env().get_CacheDir().push(self)
>>>>   File "/usr/lib/python3.7/site-packages/SCons/Node/__init__.py", line
>>>> 654:
>>>>     result = self.get_executor().get_build_env()
>>>>
>>>> On Fri, Apr 24, 2020 at 11:59 AM Bill Deegan <bill at baddogconsulting.com>
>>>> wrote:
>>>>
>>>>> Can you repro with a small example?
>>>>> --taskmastertrace=trace.log can provide some useful information.
>>>>>
>>>>> You could wrap the line 624 in a try except and have it pop into the
>>>>> debugger in the except.
>>>>>
>>>>> On Fri, Apr 24, 2020 at 9:31 AM Luke Robison <lukerobison at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I'm trying to track down a crash I have triggered in scons (both
>>>>>> 3.0.1 and 3.1.2).  This crash only happens when I ask scons to build my
>>>>>> entire output directory (it will happily compile if my command-line target
>>>>>> is build-variant/my_prog.exe, but giving it the target build-variant causes
>>>>>> the crash).
>>>>>>
>>>>>> AttributeError: 'NoneType' object has no attribute 'get_build_env':
>>>>>>   File "/usr/lib/scons/SCons/Script/Main.py", line 1376:
>>>>>>     _exec_main(parser, values)
>>>>>>   File "/usr/lib/scons/SCons/Script/Main.py", line 1339:
>>>>>>     _main(parser)
>>>>>>   File "/usr/lib/scons/SCons/Script/Main.py", line 1103:
>>>>>>     nodes = _build_targets(fs, options, targets, target_top)
>>>>>>   File "/usr/lib/scons/SCons/Script/Main.py", line 1313:
>>>>>>     jobs.run(postfunc = jobs_postfunc)
>>>>>>   File "/usr/lib/scons/SCons/Job.py", line 111:
>>>>>>     self.job.start()
>>>>>>   File "/usr/lib/scons/SCons/Job.py", line 229:
>>>>>>     task.executed()
>>>>>>   File "/usr/lib/scons/SCons/Script/Main.py", line 237:
>>>>>>     SCons.Taskmaster.OutOfDateTask.executed(self)
>>>>>>   File "/usr/lib/scons/SCons/Taskmaster.py", line 312:
>>>>>>     t.push_to_cache()
>>>>>>   File "/usr/lib/scons/SCons/Node/FS.py", line 2910:
>>>>>>     self.get_build_env().get_CacheDir().push(self)
>>>>>>   File "/usr/lib/scons/SCons/Node/__init__.py", line 624:
>>>>>>     result = self.get_executor().get_build_env()
>>>>>>
>>>>>> I have two questions:
>>>>>> 1) How can I go about debugging this?  I found --debug=pdb to be
>>>>>> usless here, as I end up in Main.py calling _build_targets rather than
>>>>>> where the error occurs.  Similarly, I can't do --tree, since python crashes
>>>>>> before it gets to that point.  Modifying the scons source with print
>>>>>> statements has been my way forward for now.
>>>>>> 2) Is it considered a bug to have scons crash like this (even if I
>>>>>> may have fed it something bad?)
>>>>>>
>>>>>> After adding some prints to the scons code, It seems one of my
>>>>>> compiled header outputs (code is Fortran, so the compiled header is
>>>>>> foo.mod) is the "self" here, and self.get_executor() returns "None", and
>>>>>> then python fails on trying to call None.get_build_env().  This crash
>>>>>> happens immediately after building the relevant SharedObject file (foo.os)
>>>>>> from the source (foo.f90).  It doesn't happen for all files, but it happens
>>>>>> predictably on some, and those tend to have no dependencies themselves.
>>>>>> Re-running the build enough times will eventually let it complete.
>>>>>>
>>>>>> Any suggestions greatly appreciated.
>>>>>>
>>>>>> Luke
>>>>>> _______________________________________________
>>>>>> Scons-users mailing list
>>>>>> Scons-users at scons.org
>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>
>>>>> _______________________________________________
>>>>> Scons-users mailing list
>>>>> Scons-users at scons.org
>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>
>>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-users at scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20200424/40dca98c/attachment.html>

More information about the Scons-users mailing list