Live data from Hacker News

The Horror in the Standard Library

zerotier.com

171–180 of 222 posts

Re: The Horror in the Standard Library

#171
post #116

Earlier quoted context omitted.

From my experience this is normal for embedded development; particularly for consumer electronics. Part of the reason some developers in this space have to wear so many hats is that the pace in consumer electronics is unforgiving. I don't think my current employer is unusual either. Hopefully, the number of frameworks at the top, and the size of your individual programs are relatively small (so that 1-3 aren't nightm…

Can confirm. I had a trippy experience where I had on one monitor some RTL+simulation for our chip up for view, on another I had the PCB schematic I had helped design, and on my third I had the GUI and embedded toolchain development environments up, and on my desk I had an oscilloscope measuring that PCB running that firmware. It was basically rolling through the list and really fun!

Indeed. I too had once the dubious pleasure of having an oscilloscope on my desk, between two computers and a prototype.

Re: The Horror in the Standard Library

#172
post #51

OMG, as I was reading this I thought, "man, this reminds me of a bug I ran into with std::string back in 2000", A few sentences later, and this is also about std::string and the STL. Mine was different though, after tracking down a memory leak that was happening with the creation of just new empty string, I discovered in the stdlib that there was a shared pointer to the empty string with a reference count of how many…

> you can't trust libraries blindly, even one of the most used and broadly adopted ones There is a corollary to development and debugging. When things break in mysterious ways, we tend to go through a familiar song and dance. As experience, skills and even personal networks grow, we can find ourselves diving ever further in the following chain. 1. "It must be in my code." -- hours of debugging 2. "Okay, it must be so…

Regarding No 10:

http://cs.dartmouth.edu/~sergey/cs258/2010/D2T1%20-%20Kris%2...

Re: The Horror in the Standard Library

#173
post #89
post #51

Earlier quoted context omitted.

> you can't trust libraries blindly, even one of the most used and broadly adopted ones There is a corollary to development and debugging. When things break in mysterious ways, we tend to go through a familiar song and dance. As experience, skills and even personal networks grow, we can find ourselves diving ever further in the following chain. 1. "It must be in my code." -- hours of debugging 2. "Okay, it must be so…

> 10. "Where is my chip lab grade oscilloscope?" 11. "Shit, where do I borrow a spectrum analyzer and a set of near field probes? These things cost an arm and a leg!" Yes, STM32F1 MCUs generate inference that jams GPS receivers. No, it's not documented anywhere.

12. "Try our new 7nm fab they said. You'll be ahead of 10nm competition with few issues. Now, gotta call engineers at the fab to see if it's materials or production messing my custom stuff up. (sighs)"

Re: The Horror in the Standard Library

#174
post #111

Earlier quoted context omitted.

11. "Do we have the IP core for this?" 12. "Where is my electron microscope?"

..13 "We're gonna need some time on the FIB workstation"[1] [1] http://www.electronicdesign.com/eda/fib-circuit-edit-becomes...

That's the one I should've thought of. I said fab but who trusts them to know what's on it!? Haha.

Re: The Horror in the Standard Library

#175
post #84
post #51

Earlier quoted context omitted.

> you can't trust libraries blindly, even one of the most used and broadly adopted ones There is a corollary to development and debugging. When things break in mysterious ways, we tend to go through a familiar song and dance. As experience, skills and even personal networks grow, we can find ourselves diving ever further in the following chain. 1. "It must be in my code." -- hours of debugging 2. "Okay, it must be so…

The furthest that I have got down the list was trying to bring up the first prototype of a board that had been designed with too long traces on the PCB between the SoC and DRAM. If you tried to read a location in memory you got the value of the page table entry for that address rather than the address contents.

Similar: my new driver crashes the machine. A couple days debugging. Triple-check every register value. All good. It doesn't crash when I single-step! A couple more days debugging. Finally get it: the machine crashes when two ports are enabled close enough in time. Go talk to the hardware guys. “Yeah, we know, power traces are fixed in the next rev.”

Re: The Horror in the Standard Library

#176

Earlier quoted context omitted.

> That'd be silly. Among many other problems, it would mean you can't do things like take a substring of a const buffer via pointer arithmetic, because you'd need to add a header in the middle Right, and now you understand​ why free should have always accepted a size parameter, just like malloc.

No, I don't. Doing zero-copy substrings of a read only buffer and an allocator chopping up a writable buffer into multiple chunks are very different scenarios.

Not for this purpose. It's all about knowing where the boundaries are.

Re: The Horror in the Standard Library

#177
post #51

OMG, as I was reading this I thought, "man, this reminds me of a bug I ran into with std::string back in 2000", A few sentences later, and this is also about std::string and the STL. Mine was different though, after tracking down a memory leak that was happening with the creation of just new empty string, I discovered in the stdlib that there was a shared pointer to the empty string with a reference count of how many…

> you can't trust libraries blindly, even one of the most used and broadly adopted ones There is a corollary to development and debugging. When things break in mysterious ways, we tend to go through a familiar song and dance. As experience, skills and even personal networks grow, we can find ourselves diving ever further in the following chain. 1. "It must be in my code." -- hours of debugging 2. "Okay, it must be so…

went through these kinds of stages a few times in my career.

once it led me to discover a leak in a major travel website's purchase flow caused by Java's Thread class, related to thread groups.

most recently, I was writing some Linux auth code in C, reached a point where I could rule out my code, and found a bug in sudo. freaking sudo.

(also related to groups, though the Linux user kind, not Java threads.)

Re: The Horror in the Standard Library

#178
post #99

Earlier quoted context omitted.

I'm curious, what is usually the cause of code starting to work when it is compiled with -O0?

I don't have an answer to that, but I have seen - and worked with - several codebases which work fine when compiled with -g, but will crash (in good cases) or behave irrationally (in bad cases) without. The crashing ones at least are easy. Somewhere a list or variable-argument array is missing the NULL terminator...

This was on Windows with VC++, but same deal. The code that some cow-orkers had written was copying strings like "LAX" and "ORD" into `char airport[3]` using strcpy(). In debug builds, VC was allocating a whole 32-bit word, but in release builds it was packing everything on the stack. Write to it, and the terminating null ends up overwriting a byte of the next variable on the stack. Urgh. Of course, these were several hundred line functions, so the strcpy and the subsequent use of the trashed variable were a long ways away.

Re: The Horror in the Standard Library

#179
post #151
post #89

Earlier quoted context omitted.

> 10. "Where is my chip lab grade oscilloscope?" 11. "Shit, where do I borrow a spectrum analyzer and a set of near field probes? These things cost an arm and a leg!" Yes, STM32F1 MCUs generate inference that jams GPS receivers. No, it's not documented anywhere.

You'd be surprised how much you can find out just with a $10 TV tuner dongle and a piece of coax with a short section of the outer braid trimmed off at once end.

You're describing my college tv antenna. Coax is cheap. An actual digital antenna is like... 50 ramen equivalents.

Re: The Horror in the Standard Library

#180
post #175
post #84

Earlier quoted context omitted.

The furthest that I have got down the list was trying to bring up the first prototype of a board that had been designed with too long traces on the PCB between the SoC and DRAM. If you tried to read a location in memory you got the value of the page table entry for that address rather than the address contents.

Similar: my new driver crashes the machine. A couple days debugging. Triple-check every register value. All good. It doesn't crash when I single-step! A couple more days debugging. Finally get it: the machine crashes when two ports are enabled close enough in time. Go talk to the hardware guys. “Yeah, we know , power traces are fixed in the next rev.”

I feel like "I can reliably make the bug disappear by turning on my debug harness" is a reliable sign that things are about to get weird.
Post reply on HN