Need help with EXC_BAD_ACCESS (not sure if it's this library)

[alexito4]

I've spent the last couple of evenings trying to figure out what's going on with no avail so I'm asking here just in case you folks see something obvious in my code.
I want to clarify that I doubt the issue is the library, or even swift, is most likely my brain having trouble 😢 but I've tried a bunch of things and I'm getting a bit desperate 😂

My code is a CLI that uses swift-parsing to get data from a text file. This PR alexito4/kindle-highlights#1 has a bunch of changes with updates on libraries and more parser. But it crashes, mostly on tests. The PR describes the scenarios that I've been able to make it crash.

When I say crash I mean EXC_BAD_ACCESS, so there is some weird memory thing going on.

In this other diff alexito4/kindle-highlights#2 you can see how I've removed pretty much all the code, leaving only Always() parsers and things have gotten better but xcode tests still fail (weirdly swift test is fine). I'm suspecting I missuse the Many parser somehow but I can't really figure it out.

What I'm doing is quite simple so there must be something basic I'm missing.

Apologies for asking debugging help but any advice is appreciated. Cheers ❤️

[tgrapperon]

Hey @alexito4! According to my tests, it doesn't crash if I'm creating a new parser each time:

var myClippingsParser: some Parser<Substring, [Highlight]> {
  Many {
      highlightParser
  } separator: {
      highlightSeparator
      Whitespace(1, .vertical)
  } terminator: {
      highlightSeparator
      Whitespace()
      End()
  }
}

I also had to do the same trick to get the suite to pass globally:
https://github.com/alexito4/kindle-highlights/compare/update-title-author...tgrapperon:kindle-highlights:update-title-author?expand=1
My long-shot guess is that this is related to top-level declarations, and that it would probably work if stored in some struct value (statically or not). I've seen weird behavior in the past with top-level stuff in command line apps, so this is what I'd tried. Or you can create parsers on the spot.
I don't think that this points toward an issue with swift-parsing however.

[alexito4]

Thanks for the quick reply @tgrapperon ! I will explore this and reply back. I wouldn't have thought about globals at all 😂

[tgrapperon]

This looked like a kind of "mutual access" issue, so I wondered what would happen if nobody would share the values and each would get its own parser, and I got lucky! I don't really know why it was problematic, so I'll read your findings with great interest!

[stephencelis]

I think when we get around to supporting body this will hopefully get better, as well:

struct MyClippingsParser: Parser {
  var body: some Parser<Substring, [Highlight]> {
    Many {
      highlightParser
    } separator: {
      highlightSeparator
      Whitespace(1, .vertical)
    } terminator: {
      highlightSeparator
      Whitespace()
      End()
    }
  }
}

We hope to return to it soon! Been tied up with Dependencies, SwiftUINavigation, and TCA tools.

[alexito4]

@stephencelis I was thinking about that when Thomas mentioned globals. There were inference issues in the reducers because of that too and the protocol move helped a lot. Happy to hear there are plans to do it here too.
But of course I'm not expecting anybody to change the focus just for this haha I didn't want to derail the great efforts you are putting in other parts right now.

[alexito4]

Just for posterity, I opened an issue in the Swift repo. swiftlang/swift#62974
Thanks folks!