Re:Eric Engstrom, co-creator of DirectX, has died
by tomduncalf on Tuesday December 15, 2020 @03:43AM
(#25428293)
Diffing log output is a great technique for tracking down weird, hard to repro bugs I find - log out as much as you can in a normal session and then in a buggy session, and diff the two, just as you describe.
Have also used this technique to compare build logs when you have a version of a project which will compile and one which doesn’t (eg when trying to integrate a second project into an existing one, or battling CI issues), useful if you aren’t an expert in that particular tool chain especially.
Personally I use VS Code’s diff these days, since they added support for word wrap recently, it’s the easiest to read.
Re:Eric Engstrom, co-creator of DirectX, has died
by HexagonalKitten on Monday December 14, 2020 @11:25PM
(#25426996)
> visual source safe (oh god, kill it with fire)
Did you have merge week too? Often stretching into a second?
Re:Eric Engstrom, co-creator of DirectX, has died
by josephg on Tuesday December 15, 2020 @06:47AM
(#25429384)
No - we had a small team (5 people). We still managed to corrupt the sourcecode database every couple of weeks and needed to reinitialize the whole thing.
Re:Eric Engstrom, co-creator of DirectX, has died
by sumtechguy on Tuesday December 15, 2020 @09:04AM
(#25430368)
We did daily backups to a second machine keeping the last 3. When it corrupted itself we copied it all back. I liked sourcesafe. It was kind of cool the way it worked and integrated into all the MS tooling we used at that time. Plus it was decently cheap enough for a small inhouse group of devs to afford. Its semantics for usage were very straightforward and easy to learn. BUT it was a pain for how it would corrupt itself randomly. That 'one' bug is why no one dares use it today and hates the thing. To this day because of how easy it was to use I compare the UX of all other source controls to it.
When debugging a web app, you can debug the code (and add print statements / breakpoints). Or look at the HTTP queries its making in the inspector. Or debug the server - look at what queries its receiving and returning. Or experiment with different values in the database.
Last year I was trying to track down a memory leak in some wasm code. The tooling for that sort of thing in wasm was/is quite primitive, so I did some work to compile the module natively then ran valgrind on the resulting executable. That didn't work - the C code executed differently from the wasm and didn't exhibit the bug! So I added print statements randomly through the program and ran it both natively and through wasm, then diffed the text output to track down when the execution traces diverged. (It wasn't a compiler bug, fwiw.)
I wanted more information about the memory leak. So I wrapped all the malloc/free calls with a replacement that stored all outstanding allocations in a list, with the stack trace when malloc was called. When the leak happened, I could ask for the stack trace of all outstanding allocated objects[1]. That was fast and effective, and I added a memory leak check in my CI.
At one of my first programming jobs we were using visual source safe (oh god, kill it with fire). I ended up losing some changes I'd made in a ~3000 line java class that we'd already deployed to production. I didn't want to do my work over again (or admit the mistake to my boss!). So I ran a decompiler against the class file we deployed to production - but it was huge and unreadable. To find the changes I'd made I took the current version of the java file, then compiled it and decompiled it again. So then I had two ugly files - but I could diff them, and that highlighted immediately the dozen or so changes I'd made. Then I just manually rewrote each change back into the original source file. Importantly, I had complete confidence that I didn't miss any of my changes.
[1] Its not pretty, but the code looks like this if anyone's curious: https://github.com/josephg/mime-to-jmap/blob/2a7429f7b805cb0...