public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
* Broken backtrace
       [not found] <64b6c88a-c06e-402d-b3a8-e5b02c39420d@zose-store-12>
@ 2011-12-13 18:05 ` Benoît Thébaudeau
  2011-12-13 19:42   ` Yann E. MORIN
  0 siblings, 1 reply; 4+ messages in thread
From: Benoît Thébaudeau @ 2011-12-13 18:05 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc

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):

[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.

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.

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

Best regards,
Benoît Thébaudeau

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Broken backtrace
  2011-12-13 18:05 ` Broken backtrace Benoît Thébaudeau
@ 2011-12-13 19:42   ` Yann E. MORIN
  2011-12-13 20:18     ` Benoît Thébaudeau
  0 siblings, 1 reply; 4+ messages in thread
From: Yann E. MORIN @ 2011-12-13 19:42 UTC (permalink / raw)
  To: crossgcc; +Cc: Benoît Thébaudeau

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Broken backtrace
  2011-12-13 19:42   ` Yann E. MORIN
@ 2011-12-13 20:18     ` Benoît Thébaudeau
  2011-12-13 23:56       ` Yann E. MORIN
  0 siblings, 1 reply; 4+ messages in thread
From: Benoît Thébaudeau @ 2011-12-13 20:18 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc

Yann, all,

> 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.

That was it: Reverting this changeset works. It removes one subshell
level, and variables are usable in all subshells.

> > 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.

Alright.

Best regards,
Benoît Thébaudeau

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Broken backtrace
  2011-12-13 20:18     ` Benoît Thébaudeau
@ 2011-12-13 23:56       ` Yann E. MORIN
  0 siblings, 0 replies; 4+ messages in thread
From: Yann E. MORIN @ 2011-12-13 23:56 UTC (permalink / raw)
  To: crossgcc; +Cc: Benoît Thébaudeau

Benoît, All,

On Tuesday 13 December 2011 21:19:12 Benoît Thébaudeau wrote:
> > OK, I just understood what happens! Thanks for pointing this.
> > Can you try to revert changeset #652e56d6d35a:
> That was it: Reverting this changeset works. It removes one subshell
> level,

I fixed it in #4193d6e6a174.
Thanks for the report.

> and variables are usable in all subshells.

I don't know what variables you ar referring to, but the goal of the
offending changset was to actually avoid variable from leaking from
one step (eg. glibc) to another step (eg. gcc).

> > > 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.

Bang! Bang!
Killed! :-)

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-12-13 23:56 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <64b6c88a-c06e-402d-b3a8-e5b02c39420d@zose-store-12>
2011-12-13 18:05 ` Broken backtrace Benoît Thébaudeau
2011-12-13 19:42   ` Yann E. MORIN
2011-12-13 20:18     ` Benoît Thébaudeau
2011-12-13 23:56       ` Yann E. MORIN

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).