Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "gdb"
-
Writes code in C
Terminal: Seg fault
Rewrites code
Terminal: Seg fault
Rewrites again, opens gdb:
Seg fault
"I should open a brewery, I like beer. I've always wanted to make beer, it's analogic for the most part. No seg faults, can you believe that? Perhaps even a pub next to the brewery..."
"Oh, I was doing one extra iteration in a for loop. Nevermind"7 -
I love GDB on CLI!
I'm using an OSS tool for multi-threaded testing stuff, and it's nice but segfaulted after 30 minutes.
I was too lazy to set up an IDE project and click through tons of stupid shit, so I just compiled the tool with debug symbols, fired up GDB on CLI, let it run until a crash, got a strack trace and quickly found the problem.
I sent a bug analysis to the author, plus a patch which got accepted, done.5 -
I propose that the study of Rust and therefore the application of said programming language and all of the technology that compromises it should be made because the language is actually really fucking good. Reading and studying how it manages to manipulate and otherwise use memory without a garbage collector is something to be admired, illuminating in its own accord.
BUT going for it because it is a "beTter C++" should not constitute a basis for it's study.
Let me expand through anecdotal evidence, which is really not to be taken seriously, but at the same time what I am using for my reasoning behind this, please feel free to correct me if I am wrong, for I am a software engineer yes, I do have academic training through a B.S in Computer Science yes, BUT my professional life has been solely dedicated to web development, which admittedly I do not go on about technical details of it with you all because: I am not allowed to(1) and (2)it is better for me to bitch and shit over other petty development related details.
Anecdotal and otherwise non statistically supported evidence: I have seen many motherfuckers doing shit in both C and C++ that ADMIT not covering their mistakes through the use of a debugger. Mostly because (A) using a debugger and proper IDE is for pendejos and debugging is for putos GDB is too hard and the VS IDE is waaaaaa "I onlLy NeeD Vim" and (B) "If an error would have registered then it would not have compiled no?", thus giving me the idea that the most common occurrences of issues through the use of the C father/son languages come from user error, non formal training in the language and a nice cusp of "fuck it it runs" while leaving all sorts of issues that come from manipulating the realm of the Gods "memory".
EVERY manual, book, coming all the way back to the K&C book talks about memory and the way in which developers of these 2 languages are able to manipulate and work on it. EVERY new standard of the ISO implementation of these languages deals, through community effort or standard documentation about the new items excised through features concerning MODERN (meaning, no, the shit you learned 20 years ago won't fucking cut it) will not cut it.
THUS if your ass is not constantly checking what the scalpel of electrical/circuitry/computational representation of algorithms CONDONES in what you are doing then YOU are the fucking problem.
Rust is thus no different from the original ideas of the developers behind Go when stating that their developers are not efficient enough to deal with X language, Rust protects you, because it knows that you are a fucking moron, so the compiler, advanced, and well made as it is, will give you warnings of your own idiotic tendencies, which would not have been required have you not been.....well....a fucking idiot.
Rust is a good language, but I feel one that came out from the necessity of people writing system level software as a bunch of fucking morons.
This speaks a lot more of our academic endeavors and current documentation than anything else. But to me DEALING with the idea of adapting Rust as a better C++ should come from a different point of view.
Do I agree with Linus's point of view of C++? fuck no, I do not, he is a kernel engineer, a damn good one at that regardless of what Dr. Tanenbaum believes(ed) but not everyone writes kernels, and sometimes that everyone requires OOP and additions to the language that they use. Else I would be a fucking moron for dabbling in the dictionary of languages that I use professionally.
BUT in terms of C++ being unsafe and unsecured and a horrible alternative to Rust I personaly do not believe so. I see it as a powerful white canvas, in which you are able to paint software to the best of your ability WHICH then requires thorough scrutiny from the entire team. NOT a quick replacement for something that protects your from your own stupidity BY impending the use of what are otherwise unknown "safe" features.
To be clear: I am not diminishing Rust as the powerhouse of a language that it is, myself I am quite invested in the language. But instead do not feel the reason/need before articles claiming it as the C++ killer.
I am currently heavily invested in C++ since I am trying a lot of different things for a lot of projects, and have been able to discern multiple pain points and unsafe features. Mainly the reason for this is documentation (your mother knows C++) and tooling, ide support, debugging operations, plethora of resources come from it and I have been able to push out to my secret project a lot of good dealings. WHICH I will eventually replicate with Rust to see the main differences.
Online articles stating that one will delimit or otherwise kill the other is well....wrong to me. And not the proper approach.
Anyways, I like big tits and small waists.14 -
So I'm writing some multithreaded shit in C that is supposed to work cross-platform. MingW has Posix threads for Windows, so that saved already half of the platform dependency. The other half was that these threads need to run external programs.
Well, there's system(), right? Uhm yes, but it sucks. It's incredibly slow on Windows, and it looks like you can have only one system() call ongoing at the same time. Which kinda defeats the multithreaded driver. Ok, but there's CreateProcessA(), and that doesn't suck.
Fine, now for Linux. The fork/exec hack is quite ugly, but it works and is even fast. Just never use fork() without immediate exec(). First try under Cygwin... crap I fork bombed my system! What is this shit? Ah I fucked up the path names so that the external executable couldn't be run.
Lesson learnt: put an exit() right after the exec() in the path for child process. Should never be reached, but if it goes there, the exit() at least prevents a fork bomb.
Well yeah, sort of works under Cygwin, but only with up to 3 threads. Beyond that, it seems like fork() at some point gives two processes the same PID, and then shit hangs.
Even slapping a mutex around the fork and releasing it only in the parent process didn't help. Fork in Cygwin is like a fork in the ass. posix_spawn() should work better because it can be mapped more easily to the Windows model, but still no dice.
OK, testing under real Linux. Yeah, no issues with that one! But instead, I get some obscure "free(): invalid size" abort. What the fuck would that even mean?! Checking my free() calls: all fine.
Time to fire up GDB in the terminal! Put a catch on the abort signal, mh got just hex data. Shit I forgot to compile with -O0 and -g. Next try. Backtrace shows the full call trace, back to the originating line in my program - which is fclose() on a file.
Ahhh I remember! Under Linux, fclosing a file that is already closed makes the program crash. So probably I was closing it twice. Checking back.. yeah that's where it was.
Shit runs fast on several cores now!8 -
Working on a C project right now, this is the only thing that comes to mind...
Good old printbugger.1 -
I always used Python as a CLI calculator. "But Python is an interpreted language and therefore slower than C". Me:8
-
The PS3 has 2 OS types: GameOS (the XMB menu and what you use to play games) and OtherOS (anything else you'd wanna load, usually Linux.) There's a problem with this: There's a build of GDB meant for OtherOS. That's great, but I need some background debugger for GameOS. Why, oh fucking WHY, has no one made a debugger like this? We have the ability to reserve compute units (SPUs) and/or areas of RAM for code to continue running when something else is loaded, why the FUCK isn't there a game debugger???10
-
I never knew that debug symbols, a core dump and gdb would be so powerful to debug
The command line is peak ol' reliable7 -
Oh boy, linux NFS bugs! this was supposed to be fixed in 2.x, but here I am, in kernel 6.1, same issue! `nfsiod` hangs, can't SIGKILL/SIGSEGV/SIGXCPU as root, `/proc/$pid/maps` is empty, strace/gdb are denied while running as root for only this process, `/proc/$pid/stack` only shows a single kthread that's stuck waiting for a fork to return, and... what the hell is `rescuer_thread`? apparently, deprecated in kernel 3.10, whatever the hell it is... wait, how did this even make a call without memory?
it's gonna be one of those days, isn't it?2 -
Now that I've spent a few ineffectual hours too many trying to get it working, I'm starting to think VS Code wasn't built for the purposes I wanted to use it for. I still can't get breakpoints working anywhere close to reliably. And I'd say breakpoints are pretty important.
On a related note, if anyone here has used VS Code together with arm-none-eabi-gdb, I'd love some pointers. I've yet to find any traces on the web of people doing that…rant frustration arm-none-eabi-gdb embedded development has anyone ever searched by tags? gdb stm32 vs code why am i still entering tags3 -
That moment when you realize that the bug (my fault, oc) was a struct declared just outside a function instead of inside it... And it "only" took you >4h of GDB and valgrind.
I really C/GTK+ when it comes to debug it... -
I'M SICK OF YOUR FUCKING HURR DURR TRIPLE FAULT HURR DURR PAGE FAULT THANKE QEMU FOR NOT EVEN BOTHERING TO TELL ME WHAT EXACTLY HAPPENS AND FUCK YOU GDB FOR NOT WORKING
-
Fucking gdb with your stupid commands, showing me the memory allocation, shos me the data you stupid piece of shit, what is the value pointed by the pointer.
*Segmentation fault**core dumped*
Oh gdb! How much I missed you. Please don't ever leave me okay? -
When gdb doesnt automatically deferences `this` but you just explicitly deference it at the start of every method:
Ps: the reference variable was literally called `dbug_mee_dawg`
Ps2: Java programmers will ***never*** understand this /s4 -
My approach to writing C++:
1. Write a test
2. If I don't understand the compiler errors, give up.
3. Run the test.
4. If it segfaults and I can't work out why in gdb, give up.
5. Make the test pass.
6. If the result is ugly and it breaks when I refactor, write a different test
7. Anything that makes it this far can be shipped. -
Finally! I can't believe the suffering has finally ended. I managed to fuck over our shiddy build system to produce normal debugging information that can be stepped in gdb. Everything goes so smoothly for me ever since.. jeez feels so good :) When I come home today Ill just lay down on a bed and roll from side to side out of happiness.
-
A friend just asked his colleagues why IntelliJ can't do reverse debugging and was told that it's impossible. It's not impossible, gdb does it, pdb does it. Probably other debuggers do it too.
Why do many devs believe that if they haven't heard of something, it doesn't exist?1 -
Why does GDB always set the bloody break point one line above or below where I want it to be. This is driving me nuts. It's like its author deliberately planted a nasty practical joke in the code.3
-
A single '=' can mess up badly:
(gdb) tb jobs.cc:541 if this->job_id_=2588573
Temporary breakpoint 1 at 0x48b571: file ../../../../../../pool/jobs.cc, line 541. -
I’m new to using gdb to debug. It could detect the places where I was getting SIGSEGV randomly. But there are also rare cases when the program just gets segmentation fault as soon as it starts, and it when that happens, even my gdb gets frozen and I have to shut down my terminal altogether.
What’s with this ? Is this some sort of kernel error (like Bus error) ? I’m using macOS Catalina and gdb 9.1.2 -
It always seems that debugging tools are almost impossible to find for the language youre learning.
Here's an entire tutorial on Go - last chapter is how to use the debugger. GAHHHH -
gdb stuck at
[New thread 0xf03 of process 39241]
When that happens I have to manually shut down the process through activity monitor or a new terminal. -
GDB&Code::Blocks got drunk together and this is apparently normal now. For like an hour already.
I DIDN'T RUN ANY FUCKING CODE IN BETWEEN THESE COMMANDS WTF IS THE DEBUGGER DOING ????3 -
Linking problems are really fun... Like using gdb in the dark on incompatible exec or without debug symbols:
You change the order of the libraries or switch to dynamic linking for one of them and suddenly it works3