git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Null pointer dereference in rerere.c
@ 2018-09-27  8:20 Ruud van Asseldonk
  2018-09-27 16:57 ` Duy Nguyen
  2018-09-27 20:40 ` Thomas Gummerer
  0 siblings, 2 replies; 4+ messages in thread
From: Ruud van Asseldonk @ 2018-09-27  8:20 UTC (permalink / raw)
  To: git

Hi,

I just ran into a segmentation fault during a rebase with rerere
enabled. Inspecting the core dump with gdb shows:

(gdb) bt
#0  0x000055d673375ce0 in do_rerere_one_path (update=0x7fff03c37f30,
rr_item=0x55d6746d0b30) at rerere.c:755
#1  do_plain_rerere (fd=3, rr=0x7fff03c37ef0) at rerere.c:853
#2  rerere (flags=flags@entry=0) at rerere.c:918
#3  0x000055d673246b01 in am_resolve (state=0x7fff03c38120) at builtin/am.c:1901
#4  cmd_am (argc=<optimised out>, argv=<optimised out>,
prefix=<optimised out>) at builtin/am.c:2394
#5  0x000055d67323f975 in run_builtin (argv=<optimised out>,
argc=<optimised out>, p=<optimised out>) at git.c:346
#6  handle_builtin (argc=<optimised out>, argv=<optimised out>) at git.c:554
#7  0x000055d6732405e5 in run_argv (argv=0x7fff03c394a0,
argcp=0x7fff03c394ac) at git.c:606
#8  cmd_main (argc=<optimised out>, argv=<optimised out>) at git.c:683
#9  0x000055d67323f64a in main (argc=4, argv=0x7fff03c396f8) at common-main.c:43
(gdb) info locals
path = 0x55d6746d08e0 "<file path redacted>"
id = 0x55d6746d01e0
rr_dir = 0x55d6746ccb80
variant = <optimised out>
path = <optimised out>
id = <optimised out>
rr_dir = <optimised out>
variant = <optimised out>
both = <optimised out>
vid = <optimised out>
path = <optimised out>
(gdb) print id
$1 = (struct rerere_id *) 0x55d6746d01e0
(gdb) print id->collection
$2 = (struct rerere_dir *) 0x55d6746ccb80
(gdb) print id->collection->status
$3 = (unsigned char *) 0x0

This is using Git 2.17.1 from the 1:2.17.1-1ubuntu0.1 Ubuntu package.
Looking at the diff between v2.17.1 and master for rerere.c it looks
like the part of the rerere.c where the null pointer dereference
happens has not been touched, so the issue might still be there.
Unfortunately I was unable to reproduce the bug; after removing
.git/MERGE_RR.lock and restarting the rebase, it completed fine.

Please let me know if there is anything I can do to help diagnose the
problem, or whether I should report the bug to Ubuntu instead.

Kind regards,

Ruud van Asseldonk

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

* Re: Null pointer dereference in rerere.c
  2018-09-27  8:20 Null pointer dereference in rerere.c Ruud van Asseldonk
@ 2018-09-27 16:57 ` Duy Nguyen
  2018-09-27 20:40 ` Thomas Gummerer
  1 sibling, 0 replies; 4+ messages in thread
From: Duy Nguyen @ 2018-09-27 16:57 UTC (permalink / raw)
  To: ruud; +Cc: Git Mailing List

On Thu, Sep 27, 2018 at 10:24 AM Ruud van Asseldonk <ruud@channable.com> wrote:
> Please let me know if there is anything I can do to help diagnose the
> problem.

Nothing yet but please keep the core dump. We might be able to dig
some more out of it to confirm if we find something suspicious.
-- 
Duy

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

* Re: Null pointer dereference in rerere.c
  2018-09-27  8:20 Null pointer dereference in rerere.c Ruud van Asseldonk
  2018-09-27 16:57 ` Duy Nguyen
@ 2018-09-27 20:40 ` Thomas Gummerer
  2018-10-01  7:21   ` Ruud van Asseldonk
  1 sibling, 1 reply; 4+ messages in thread
From: Thomas Gummerer @ 2018-09-27 20:40 UTC (permalink / raw)
  To: Ruud van Asseldonk; +Cc: git

On 09/27, Ruud van Asseldonk wrote:
> Hi,
> 
> I just ran into a segmentation fault during a rebase with rerere
> enabled. Inspecting the core dump with gdb shows:

Thanks for reporting this bug

> (gdb) bt
> #0  0x000055d673375ce0 in do_rerere_one_path (update=0x7fff03c37f30,
> rr_item=0x55d6746d0b30) at rerere.c:755
> #1  do_plain_rerere (fd=3, rr=0x7fff03c37ef0) at rerere.c:853
> #2  rerere (flags=flags@entry=0) at rerere.c:918
> #3  0x000055d673246b01 in am_resolve (state=0x7fff03c38120) at builtin/am.c:1901
> #4  cmd_am (argc=<optimised out>, argv=<optimised out>,
> prefix=<optimised out>) at builtin/am.c:2394
> #5  0x000055d67323f975 in run_builtin (argv=<optimised out>,
> argc=<optimised out>, p=<optimised out>) at git.c:346
> #6  handle_builtin (argc=<optimised out>, argv=<optimised out>) at git.c:554
> #7  0x000055d6732405e5 in run_argv (argv=0x7fff03c394a0,
> argcp=0x7fff03c394ac) at git.c:606
> #8  cmd_main (argc=<optimised out>, argv=<optimised out>) at git.c:683
> #9  0x000055d67323f64a in main (argc=4, argv=0x7fff03c396f8) at common-main.c:43
> (gdb) info locals
> path = 0x55d6746d08e0 "<file path redacted>"
> id = 0x55d6746d01e0
> rr_dir = 0x55d6746ccb80
> variant = <optimised out>
> path = <optimised out>
> id = <optimised out>
> rr_dir = <optimised out>
> variant = <optimised out>
> both = <optimised out>
> vid = <optimised out>
> path = <optimised out>
> (gdb) print id
> $1 = (struct rerere_id *) 0x55d6746d01e0
> (gdb) print id->collection
> $2 = (struct rerere_dir *) 0x55d6746ccb80
> (gdb) print id->collection->status
> $3 = (unsigned char *) 0x0
> 
> This is using Git 2.17.1 from the 1:2.17.1-1ubuntu0.1 Ubuntu package.
> Looking at the diff between v2.17.1 and master for rerere.c it looks
> like the part of the rerere.c where the null pointer dereference
> happens has not been touched, so the issue might still be there.
> Unfortunately I was unable to reproduce the bug; after removing
> .git/MERGE_RR.lock and restarting the rebase, it completed fine.

I do believe this bug may actually be fixed in master, by 93406a282f
("rerere: fix crash with files rerere can't handle", 2018-08-05).  Do
you by any chance remember if you committed a file that contained
conflict markers during the rebase at some point?

The problem I found at the time looked the same as your backtrace
above in any case.

Would have been nice if you were able to reproduce it, just to make
sure it's not something else we're seeing here.

> Please let me know if there is anything I can do to help diagnose the
> problem, or whether I should report the bug to Ubuntu instead.
> 
> Kind regards,
> 
> Ruud van Asseldonk

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

* Re: Null pointer dereference in rerere.c
  2018-09-27 20:40 ` Thomas Gummerer
@ 2018-10-01  7:21   ` Ruud van Asseldonk
  0 siblings, 0 replies; 4+ messages in thread
From: Ruud van Asseldonk @ 2018-10-01  7:21 UTC (permalink / raw)
  To: t.gummerer; +Cc: git

> I do believe this bug may actually be fixed in master, by 93406a282f
> ("rerere: fix crash with files rerere can't handle", 2018-08-05).  Do
> you by any chance remember if you committed a file that contained
> conflict markers during the rebase at some point?

I might have, but I am not 100% sure.

> The problem I found at the time looked the same as your backtrace
> above in any case.

Thanks for checking. I will keep the core dump and report back if it
ever happens again.

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

end of thread, other threads:[~2018-10-01  7:21 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-27  8:20 Null pointer dereference in rerere.c Ruud van Asseldonk
2018-09-27 16:57 ` Duy Nguyen
2018-09-27 20:40 ` Thomas Gummerer
2018-10-01  7:21   ` Ruud van Asseldonk

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 NNTP newsgroup(s).