4 ms·
I remember compiling and working with Firefox code many years ago, one thing that surprised me were non-fatal assertion errors continuously printing errors to c
by mixedbit 9y ago
I remember compiling and working with Firefox code many years ago, one thing that surprised me were non-fatal assertion errors continuously printing errors to console in debug build. It looked like Netscape legacy, I wonder if they managed to clean this.
- avian 9y agoFirefox ESR 52.2.0 on Debian still prints a whole bunch of assertion errors if you run it in a terminal: (firefox-esr:345): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed
- dom0 9y agoI've never seen any Gtk application that does not spew messages like this at least occasionally.
- yrro 9y agoDevelopers should be running with G_DEBUG=fatal-criticals so that those warnings convert into program crashes. But then again developers shouldn't have been writing anything in a language that requires manual resource management since C++.
- Gikoskos 9y agoI've noticed this as well in all the Gtk apps that I've run through the terminal. Never having programmed in Gtk, what is the cause of this? Is Gtk broken or are all the programmers using it incorrectly? I've programmed a great deal in WinAPI and stuff like that never happens.
- ordu 9y agoWinAPI does not print into console warnings about accidental attempt to drop ref-counted object that has dropped already. So how can you know? Maybe it happens with WinAPI all the time silently.
- onli 9y agoNo one knows how to use GTK correctly, not even the GTK developers. At least that was the situation in 2014 when subsurface moved from GTK to Qt, https://www.youtube.com/watch?v=ON0A1dsQOV0 https://www.youtube.com/watch?v=ON0A1dsQOV0.
- 77pt77 9y agoI think this is very common. There's a bunch of boilerplate code that just gets carried from project to project. My favourite was when KDE decided to move to cmake. People realized that most m4/autoconf macros were there for no reason and no one actually knew what they checked for let alone how.
- revelation 9y agoYou might like this essay: http://queue.acm.org/detail.cfm?id=2349257 http://queue.acm.org/detail.cfm?id=2349257
- 77pt77 9y ago> Sam Leffler's graphics/libtiff is one of the 122 packages on the road to www/firefox, yet the resulting Firefox browser does not render TIFF images Don't even get me started on the circular dependencies that need to be broken by installing packages with some options disabled. Kind of an awkward bootstrap.
- rleigh 9y agoI added CMake support to libtiff last year. Haven't checked if the ports tree uses it yet.
- realusername 9y agoI can confirm in my case, I coded a lot with Gtk a while ago and these warnings are close to impossible to avoid.
- camus2 9y agoGiven how GObject is implemented (void pointers everywhere ), that's not surprising.
- mort96 9y agoHow are you supposed to make data structures which work with any type without void pointers in C?
- sebcat 9y agoIt's not just Gtk. At $WORK, we have a lot of user space daemons where everything boils down to GLib, and GIO for all IPC. We do our own hardware and kernel development (upstream kernel + .ko's for our stuff) and that's good code. Then we have the daemons in userland providing interfaces to ioctl's and cdevs, with some house keeping and interfaces for DBus and HTTP APIs. All the userland stuff just vomits GLib-CRITICAL messages. No one bothers to check for them because everything is running as daemons with stderr redirected to /dev/null... And $WORK is one of the better places I've worked at. I am certain that if those assertions would have been fatal, they would have been fixed a long time ago.
- yrro 9y agoDevelopers should be running with G_DEBUG=fatal-criticals...
- hsivonen 9y agoThe newer MOZ_ASSERT is fatal in debug builds. The non-fatal legacy NS_ASSERTION still exists and unit tests complain if the number of times it fires for a given test changes. So it's under control, but the Netscape-era assertions haven't all been converted to reliable assertions.