Re: Broken backtrace

["Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>]

Benoît, All,

On Tuesday 13 December 2011 19:06:18 Benoît Thébaudeau wrote:
> Hi Yann, all,
> 
> I'm not sure if it was already the case with previous Ubuntus, but CT-NG's
> backtrace is broken at least with Ubuntu 11.10 (using bash):

It's also broken here on Debian Squeeze.
I have not yet investigated too much, but I plan on doing so after I finish
some more important stuff (eg. multilib, canadian...).

> [INFO ]  Installing PPL: done in 7912.66s (at 198:02)
> [INFO ]  Saving state to restart at step 'cloog'...
> [INFO ]  =================================================================
> [INFO ]  Installing CLooG/ppl
> [ERROR]    make[2]: *** [cloog] Error 1
> [ERROR]    make[1]: *** [check-recursive] Error 1
> [ERROR]
> [ERROR]    >>
> [ERROR]    >>  Error happened in: main[scripts/crosstool-NG.sh]
> [ERROR]    >>
> [ERROR]    >>  For more info on this error, look at the file: 'build.log'
> [ERROR]    >>  There is a list of known issues, some with workarounds, in:
> [ERROR]    >>      '/Toolchains/crosstool-ng/build/share/doc/ct-ng-hg+default-69cfd6e0f1d1/B - Known issues.txt'
> [ERROR]
> [ERROR]    Build failed in step 'Extracting and patching toolchain components'
> [ERROR]
> [ERROR]    (elapsed: 198:20.71)
> 
> The step should have been 'Installing CLooG/ppl', and the calls should have been
> backtraced.
> 
> I've performed some tests, which show that this issue is caused by the following
> lines:
> 
>     14     # Bail out early in subshell, the upper level shell will act accordingly.
>     15     [ ${BASH_SUBSHELL} -eq 0 ] || exit $ret
> 
> http://crosstool-ng.org/hg/crosstool-ng/file/096845dbd877/scripts/functions#l14
> 
> The trace should be displayed for the deepest subshell, not for the top one.
> 
> For this example, I end up with subshells 2 to 0, and the trace variables
> CT_STEP_COUNT and CT_STEP_MESSAGE are correct only for subshells 2 and 1. For
> subshell 0, these variables are like before do_cloog() is called, i.e. 1 for
> ${CT_STEP_COUNT}, "<none>" for ${CT_STEP_MESSAGE[1]} and "Extracting and
> patching toolchain components" for ${CT_STEP_MESSAGE[2]}. CT_OnError() sets
> CT_STEP_COUNT to 2 before logging ${CT_STEP_MESSAGE[${CT_STEP_COUNT}]}, hence
> the result.

OK, I just understood what happens! Thanks for pointing this.
Can you try to revert changeset #652e56d6d35a:

    scripts: execute each steps in a subshell

    To avoid variable leakage from one step to another, isolate the
    steps from each others by running them in their own sub-shell.

    This avoids variables leaking from one step to the others.


> Notes regarding CT_OnError() (nothing to do with this issue):
>  - The step variable (already used in main()) could be defined as local to be
> cleaner, even if it does not really matter when exiting.
>  - "offset=1" seems to be a spurious line.

Probably both right, I'll look after dinner.

> As to the error itself of my example, I'm testing a patch I've just cooked.

Thank you!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq