Weird file corruption in very specific circumstances

[davidgiven]

Okay, this is a weird one. It's sufficiently touchy that I have to use my entire project as a test case (it's not that big).

bogomandel-master.zip

Build with:

beebasm -i src/mandel.asm -do mandel.ssd -opt 3 -w

...and it works.

Now edit src/shell.bas. On line 35 there is a space before the number 5. Remove this space and rebuild.

The resulting image won't work. The mandel, setscrn, squarep and squaren files in the SSD are garbage --- but !boot, loader and shell are fine. Building without the -do option produces perfectly valid files.

This is on Debian, using the current head of git (9317003).

[mungre]

I tried this on Windows and in Windows 10's Ubuntu environment, using both the head of master (9317003) and the head of proposed-updates (e2b2a19) and with and without the space on line 35.

Then I remembered I had a debian93 VM so I installed everything there.

They all worked. I can't reproduce the problem.

The mandelbrot project is enormously impressive though.

[ZornsLemma]

I just tried this on my Ubuntu 16.04.4 amd64 box and I can't reproduce it either. :-( But I also agree with mungre the mandelbrot project is enormously impressive.

(This is also the first time I've seen beebasm take a significant amount of time to assemble something! I haven't dug into the source yet, but I hope it's doing something pretty heavyweight - I'm guessing table building stuff.)

I also tried running beebasm under valgrind (just quickly, without playing with any options) and it didn't show anything dodgy here either.

Is there any chance you could try valgrind yourself on the offchance there is some useful output? Can you reproduce it with a debug build of beebasm?

Incidentally, thanks very much for raising these bugs - you're obviously giving beebasm a real workout!

ETA: If all else fails, I'll do a code review of the BASIC tokenising code and see if I can spot anything iffy, although I've used it quite a bit in my own projects and it's been fine so I don't really like to point fingers at it.

[davidgiven]

Fair enough. It's so flaky that the differences between your system and mine will be masking whatever's happening.

I can still reproduce it here --- even after the last bunch of bogomandel changes, which is interesting. I've also checked proposed-updates and it fails there too.

Adding another blank line to the end of the file in place of the space causes things still to go wrong, so it's not a simple file size issue. I'll have a look on my system. It's quite clean on valgrind.

(Incidentally, I found another seg fault: line 757 of BASIC.cpp eats characters without checking for EOF, so if there are two blank lines at the end of the file it eats forever until it overruns the buffer and then crashes...)

(Also, Beebasm is great; I wish there was a Z80 version for my other projects! I really like the put-code-on-a-blank-canvas mode of operation. There are only two features I really miss: O%, allowing code to be placed in a different location to where it's assembled for, although COPYBLOCK works around this to a large extent; and numbered labels with forward/backward references. This allows things like cmp #7; beq 1f; jsr fnord; .1 without needing to open a scope or think about a label name.)

(Oh, and string parameters to macros would be nice. Also, got any ponies?)

[ZornsLemma]

Should we start raising issues to track potential enhancements to beebasm or is that going to clutter things up? I can imagine some discussion over on stardot about some changes, but I know there are quite a few good ideas floating around and it would be a shame to lose them.

[mungre]

At the right-hand side of the top comment there is a box that lets you label issues as a bug or enhancement, amongst other things.

So yes, adding enhancements as issues is a good idea and the labelling will keep them distinct from the bugs.

[davidgiven]

I've figured out why you're having trouble reproducing this --- it's not a beebasm bug at all; it's a b-em bug. The .ssd file runs fine in mame and jsbeeb, and fails reliably in b-em. Which is very, very weird.

Apologies for the noise!

[ZornsLemma]

Thanks for letting us know, and I see from the b-em issue tracker you've managed to find the cause now - I'll be interested to see how this gets resolved.