What is the meaning of the 200 __clone lines in backtraces?

[Bruno Jesus]

Hi all, this is something I have been curious for a long time. When an
application crashes it is very common to see that the
backtraces at some point start showing:

42 0xf750962e __clone+0x5d() in libc.so.6 (0x00000000)
  43 0xf750962e __clone+0x5d() in libc.so.6 (0x00000000)
  44 0xf750962e __clone+0x5d() in libc.so.6 (0x00000000)
  45 0xf750962e __clone+0x5d() in libc.so.6 (0x00000000)

Up to 200. Is this a bug or it is just not possible to identify when
the backtrace ends and 200 is a hard limit or what else could it be?

Best wishes,
Bruno

[Qian Hong]

Hi Bruno,

On Fri, Nov 27, 2015 at 12:36 AM, Bruno Jesus  wrote:
> Up to 200. Is this a bug or it is just not possible to identify when
> the backtrace ends and 200 is a hard limit or what else could it be?

'Up to 200' is limited by WineDbg

stack.c:
185  * Do a backtrace on the current thread
186  */
187 unsigned stack_fetch_frames(const CONTEXT* _ctx)

239         if (nf > 200 || !ret) break;

There is also:
dbg.tab.c:/* YYINITDEPTH -- initial size of the parser's stacks.  */
dbg.tab.c:#ifndef YYINITDEPTH
dbg.tab.c:# define YYINITDEPTH 200

However, I'm also curious by repeat of '__clone', I don't understand
this part, hopefully someone else can explain it ;-)

[Daniel Santos]

On 11/26/2015 03:40 PM, Qian Hong wrote:
> Hi Bruno,
>
> On Fri, Nov 27, 2015 at 12:36 AM, Bruno Jesus  wrote:
> > Up to 200. Is this a bug or it is just not possible to identify when
> > the backtrace ends and 200 is a hard limit or what else could it be?
>
> 'Up to 200' is limited by WineDbg
>
> stack.c:
> 185  * Do a backtrace on the current thread
> 186  */
> 187 unsigned stack_fetch_frames(const CONTEXT* _ctx)
>
> 239         if (nf > 200 || !ret) break;
>
> There is also:
> dbg.tab.c:/* YYINITDEPTH -- initial size of the parser's stacks.  */
> dbg.tab.c:#ifndef YYINITDEPTH
> dbg.tab.c:# define YYINITDEPTH 200
>
> However, I'm also curious by repeat of '__clone', I don't understand
> this part, hopefully someone else can explain it ;-)

Funny timing on this question. I've had a patch for this sitting in my local branch for a month or so and finally submitted it last night (attached). My guess has always been that when a process is forked (since that's how Linux babies are made) that something wasn't reading that stack frame correctly and just looped it. The call to clone would have happened in the process that spawned us, like /bin/bash if you started it from a bash shell.

There's likely a cleaner approach than this patch, but this one at least makes "backtrace all" readable for me.

Daniel