Login

Become a leader in the IoT community!

Join our community of embedded and IoT practitioners to contribute experience, learn new skills and collaborate with other developers with complementary skillsets.

Step 1 of 5

CREATE YOUR PROFILE *Required

Step 2 of 5

WHAT BRINGS YOU TO DEVHEADS? *Choose 1 or more

Connect & collaborate 🤝with other tech professionals

I want to connect & collaborate with other techies

Learn & Grow 📚

Learn from our helpers & grow your tech knowledge

Contribute Experience & Expertise 🔧

Become a helpful hacker & assist others by sharing

Step 3 of 5

WHAT'S YOUR INTEREST OR EXPERTISE? *Choose 1 or more

Hardware Design 💡

PCB design, analog circuits, and more.

Embedded Software 💻

Embedded OS, firmware/middleware, debug & tools

Edge Networking ⚡

Real-time/low-power connectivity & IoT device management

Step 4 of 5

Personalize your profile

Step 5 of 5

Read & agree to our COMMUNITY RULES

We want this server to be a welcoming space! Treat everyone with respect. Absolutely no harassment, witch hunting, sexism, racism, or hate speech will be tolerated.
If you see something against the rules or something that makes you feel unsafe, let staff know by messaging @admin in the "support-tickets" tab in the Live DevChat menu.
No age-restricted, obscene or NSFW content. This includes text, images, or links featuring nudity, sex, hard violence, or other graphically disturbing content.
No spam. This includes DMing fellow members.
You must be over the age of 18 years old to participate in our community.
You agree to our Terms of Service (https://www.devheads.io/terms-of-service/) and Privacy Policy (https://www.devheads.io/privacy-policy)

By clicking "Finish", you have read and agreed to the our Terms of Service and Privacy Policy.

Debugging Persistent Segmentation Fault in Multi-threaded C++ Program on AMD Barcelona CPUs

Posted by Marvee Amasi
11:30 am
21/11/2024

I have been wrestling with a persistent segmentation fault in a multi-threaded C++ program running on a cluster of AMD Barcelona CPUs Linux/x86_64. The code causing the crashes is a heavily used function, and under load, running 1000 instances of the program same optimized binary can generate 1 to 2 crashes per hour.
Now here’s the interesting part, the crashes happen on different machines within the cluster although the machines themselves are almost identical, and they all share the same characteristics – same crash address and call stack.