Incorrect parsing of code block inside list

[5225225]

#[test]
fn test_bad_slice_c() {
    parse("+ `\nx\n**\n  *\n  `")
}

Panics with

thread 'test_bad_slice_c' panicked at 'begin <= end (15 <= 14) when slicing `+ `
x
**
  *
  ``', src/parse.rs:802:35

This is deep in the nest of parsing internals, and I have no clue how the parser works here. So uhh.... good luck!

I tried to minimise the test case by removing single characters, and couldn't make it any smaller than this.

[marcusklaas]

What a beauty! Not only have you found another bug, but you have also challenged my, apparently incorrect, belief that fuzzers either find something in the first minute or nothing at all :-)

I'll have a crack at this.

Thanks again for reporting an interesting catch!

[marcusklaas]

So uhh.... good luck!

:D

[marcusklaas]

Keeping this open to remind us to not only not panic, but also render it correctly!

[5225225]

Cool! Thanks for the fast fix.

I'll leave a fuzzer running overnight and see what happens.

My previous fuzzing was actually running on ASCII only with a limited character set purely to not find too many issues, but it seems like all the easy to find issues are indeed done, and we're now finding the Spicy:tm: issues, so I'll run it with "any valid &str".

[marcusklaas]

Haha, I'm super eager to see what 🌶️ issues you will find!

[marcusklaas]

Oh no, I just tried fuzzing with

let parser = Parser::new_ext(data, Options::all());

and it found panics immediately 🙈

Still lots of work to do!

[marcusklaas]

Both "\n # #\r\u{1c} " and "<\n #\t%\r\u{0}" produce panics...

[marcusklaas]

Looking at this tomorrow 😅

[5225225]

Ah, right! Yes, I've been fuzzing with default options...

I'll amend my PR (#562) to fuzz both the input and the options.

[Martin1887]

Is this still an issue, @5225225? If it is, I will try to fix it.

Thanks.

[5225225]

The panic has been fixed, but the behavior is incorrect (See the discussion in the PR #563). I'll change the issue title to reflect that.

[Martin1887]

OK, I see this less relevant then, I will try to solve it in the future but it is less urgent now.

[Martin1887]

This has been fixed, a space between the first two asterisks and the last one is rendered inside the code block now. Surely fixed by one of the latest pull requests about handling emphasis.