[Scons-users] Determining source of scons crash

[Luke Robison]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20200424/f8951a6a/attachment-0001.html>