Port to a new backend? (was: segfault on OS X Mojave)

[kousu]

Port to a new backend? (was: segfault on OS X Mojave)

[kousu]

I traced what zxing and you are doing differently.

You're calling decodeMultiple():

zxinglight/zxinglight/_zxinglight.cpp

Lines 66 to 70 in 6dd20ae

	Ref<BinaryBitmap> bitmap(new BinaryBitmap(binarizer));
	MultiFormatReader delegate;
	GenericMultipleBarcodeReader reader(delegate);
	vector<Ref<Result> > results = reader.decodeMultiple(bitmap, hints);

they're only calling that if you pass --search-multi:

https://github.com/glassechidna/zxing-cpp/blob/b80a24cc6e6dc6f119048ca85c5e76938a516cfb/cli/src/main.cpp#L84-L88

Indeed, I can reproduce the exact same crash. It's bizarre; I don't read asm that well but it looks like my compiler hard-coded %rdi=*(0x18), followed by `%rdi==*(0x20), which is impossible since 0x18 and 0x20 are obviously a special off-limits memory address, just like the error ("Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000018") says.

$ lldb -- zxing --more --search-multi code.png 
(lldb) target create "zxing"
Current executable set to 'zxing' (x86_64).
(lldb) settings set -- target.run-args  "--more" "--search-multi" "code.png"
(lldb) run
Process 14786 launched: '/usr/local/bin/zxing' (x86_64)
Process 14786 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x18)
    frame #0: 0x00000001000483af zxing`zxing::multi::GenericMultipleBarcodeReader::translateResultPoints(zxing::Ref<zxing::Result>, int, int) + 249
zxing`zxing::multi::GenericMultipleBarcodeReader::translateResultPoints:
->  0x1000483af <+249>: movq   0x18, %rdi
    0x1000483b7 <+257>: cmpq   0x20, %rdi
    0x1000483bf <+265>: je     0x1000483dc               ; <+294>
    0x1000483c1 <+267>: movq   $0x0, (%rdi)
Target 0: (zxing) stopped.
(lldb) 

[lubo]

Hi, @kousu. Thanks for opening this issue. At first glance, it looks to me like this is coming from ZXing itself. Unfortunately, I don't use OS X and therefore I'm unable to help you with this one.

[kousu]

Well, I wrote #6 as a workaround, so when that goes in I'll be happy enough :) And it seems that if I build from source instead of using brew's packages the problem goes away, so the bug isn't with you at all.

But it seems that me making a fuss has maybe convinced zxing-cpp to finally give up 😨 , and it got deleted from brew this morning after they'd been thinking about doing it for a while 😭 , so you might be losing your upstream sometime soon.

There's a replacement zxing-cpp that @glassechidna recommended with a better API maybe? I also am personally all about this tiny BSD-licensed, pure-C library; it looks like it would be easier to wrap, while maintaining the API. It only works in multimode.

[lubo]

I've created #7 and I'd prefer to take any further discussion about porting this package to nu-book/zxing-cpp there. Since this issue reports a bug that in fact isn't a bug in this package, I'm closing it.

When it comes to porting to other decoder backends, I think it'd be better if somebody came up with another package. This one was designed to be a simple wrapper around ZXing rather than a catch-all multi-backend (bar)code toolkit.