Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Horror in the Standard Library

zerotier.com

Post reply on HN
Print view View original

131–140 of 222 posts

Re: The Horror in the Standard Library

#131

Post by djsumdog »

charles-salvia wrote: post #28

I'm a bit confused here. >> Most operators in C++, including its memory allocation and deletion operators, can be overloaded. Indeed this one was. Okay, well, firstly - the issue here seems to be a problem with the implementation of std::allocator, rather than anything to do with overloading global operator new or delete. Specifically, it sounds like the blog author is talking about one of the GNU libstdc++ extension…

I too was curious about what distribution they were using; specifically which GNU libstdc++ packages. It seems like a drill down to that specific distribution's rpm/deb/etc packaging scripts to see their ./configure options would also be important.

Re: The Horror in the Standard Library

#132

Post by twic »

theoh wrote: post #16
cortesoft wrote: post #11

Earlier quoted context omitted.

I am pretty sure there has never been a carpenter who resmelted his hammer.

I'm not sure "resmelting" is even a thing. I am sure that the GP is joking.

It seems it is:

http://www.khm.uio.no/english/research/projects/langeid/proj...

Re: The Horror in the Standard Library

#134

Post by fest »

rjsw wrote: post #84
bostik wrote: 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.

I've had the opportunity spend about a week debugging incorrect configuration of SDRAM by BSP team. At first I blamed third party library with no source code available. Then it occurred to me that my initial SDRAM tests were doing word-by-word access. Third party library used memset which was optimised to use DMA for bulk transfers, which failed to write subsequent words in the same transaction.

An easy, one bit change in configuration registers of SDRAM fixed it. A week well spent!

Re: The Horror in the Standard Library

#135

Post by northern_lights »

kosma wrote: post #89
bostik wrote: 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.

any MCU can "jam" a GPS receiver if the board is laid out improperly or without enough shielding

Re: The Horror in the Standard Library

#137

Post by bogomipz »

This was a nice write up, however I didn't follow how memory fragmentation was related to a memory leak. Can someone explain? I understand that alternate memory allocators would help with the fragmentation issue but how does the choice of allocators affect memory leakage?

Re: The Horror in the Standard Library

#138

Post by TwoBit »

badsectoracula wrote: post #92
CamperBob2 wrote: post #56

Earlier quoted context omitted.

Notes about deallocation. This allocator does not explicitly release memory. Because of this, memory debugging programs like valgrind or purify may notice leaks: sorry about this inconvenience. Operating systems will reclaim allocated memory at program termination anyway. Wow. This is worth a Linus Torvalds-level rant. Whoever accepted this code into the source tree needs to be put on GNU's version of a performance i…

This is actually a fine thing to do, i don't remember where i read it, but a good analogy for trying to free memory at program exit is like trying to clean the floors and walls of a building right before it is demolished. This is also why Valgrind separates reachable and unreachable memory and only considers unreachable memory as leaks.

It's OK to do, but it makes memory analysis difficult. If your app exits with a lot of allocated memory, it's hard to tell what's a real leak and what's not.

Re: The Horror in the Standard Library

#139

Post by faragon »

gravypod wrote: post #109
faragon wrote: post #94

The problem is forgetting that dynamic memory usage is not "free" (as in "gratis" or "cheap"). In fact, using std::string for long-lived server processes doing intensive string processing (e.g. parsing, text processing, etc.) is already known to be suicidal since forever, because of memory fragmentation. For high load backend processing data, you need at least a soft real-time approach: avoid dynamic memory usage at…

Are you still developing this project?

Yes

Re: The Horror in the Standard Library

#140

Post by mighty_atomic_c »

uep wrote: post #116
bostik wrote: 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…

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!
Post reply on HN