Life without core dump, is it possible?

Status
Not open for further replies.
B

badbrain

Guest
On OpenIndiana I constantly got a file named core on my home dir that I didn't know which application generated it. When I restart and log in again I see this file again. Each time with different size. Then I tried DragonFlyBSD. Thing's worse. Firefox always core dump and give a hundred megabytes core file on my home dir. I can't even start and browse normally it's just crash. Too disappointed I come back to FreeBSD. And greeted my on my first login is marco.core and gnome-keyring-daemon.core! It core dumped everytime I login, each time with different size. I'm not even dare to open Firefox, feared if it will be like what's on DragonFlyBSD :( All of my installations are fresh and I didn't tweak anything. The only VM doesn't give core dump is MX Linux. Now I know why people hate Linux-only-(in-mind) software :(
 
How about running a memory tester? Absence of core dumps does not mean nothing is wrong.
 
How about running a memory tester? Absence of core dumps does not mean nothing is wrong.
Something like memtest86? No, my system is branch new.
If it's something like gdb, I don't know how to use gdb.
 
Firefox also core dump but usable. I'm posting using it now. Not as bad as DragonFlyBSD.
 
Back to Windows. I don't know how to deal with .core file. Here is the list of them:

6691


Firefox.core is nearly 200mb and the later both nearly 10mb (this time).

I also considered to upload them to somewhere on the net so people could study them but then I think no one would download such a random file from the net so I give up.

p/s: default FreeBSD mate desktop is too ugly.
 
file will tell you the binary that produced the core. Then use gdb with the binary and core as arguments. It will tell you some stuff. The ''bt' command in gdb will give you a backtrace.
 
On NetBSD and OpenBSD there's no core dump. Everything just works but without the guest addition. Was the guest addition caused all of this?
p/s: No, it's not right. DragonFlyBSD also doesn't have guest addition but also core dump. I don't understand why.
 
file will tell you the binary that produced the core. Then use gdb with the binary and core as arguments. It will tell you some stuff. The ''bt' command in gdb will give you a backtrace.
Thank you for still care about me but I can't follow. I don't mess with gdb 😫
 
maybe you are looking for this:
----- /etc/sysctl.conf -----
kern.corefile=/dev/null
----------------------------
So just forget about them if everything still work? OK, I will do this. I wonder does this only work with system core file? I have userland software core dump I'm afraid.
 
Make sure you have hald / dbus running and procfs mounted. I remember that fixing a few issues. Also Policy kit by default is completely unset so you might need to fiddle with that to allow permissions if it helps with some crashes.

Gnome 2 used to work around the 2.16 version very well; it even had mounting.... for some absolutely mad reason we ended up with a broken version (2.30) just because it "sounded more recent" and we never quite recovered. This result also translates to MATE (a fork).

Back to Windows.

If you run marco on Windows, it will still crash. It is just slightly flaky software. Marco is part of the MATE desktop (I think it is the file manager) and even since Gnome 2 I remember it leaving a bunch of core dumps around.

Try to simplify your software usage a little. Pick something like LXDE because it has less complexity (less things to break) and if something does break, you can simply give it the boot and replace it with something better written.

Once Gnome 3 has run its course and finally died, you might find resources return back to Mate and it gets a little bit more polish.

If you want a big desktop environment, try an older one like KDE 3.5 (OpenBSD is the only one with a port as far as I know). This and CDE works pretty well.
 
Make sure you have hald / dbus running and procfs mounted. I remember that fixing a few issues. Also Policy kit by default is completely unset so you might need to fiddle with that to allow permissions if it helps with some crashes.

Gnome 2 used to work around the 2.16 version very well; it even had mounting.... for some absolutely mad reason we ended up with a broken version (2.30) just because it "sounded more recent" and we never quite recovered. This result also translates to MATE (a fork).



If you run marco on Windows, it will still crash. It is just slightly flaky software. Marco is part of the MATE desktop (I think it is the file manager) and even since Gnome 2 I remember it leaving a bunch of core dumps around.

Try to simplify your software usage a little. Pick something like LXDE because it has less complexity (less things to break) and if something does break, you can simply give it the boot and replace it with something better written.

Once Gnome 3 has run its course and finally died, you might find resources return back to Mate and it gets a little bit more polish.

If you want a big desktop environment, try an older one like KDE 3.5 (OpenBSD is the only one with a port as far as I know). This and CDE works pretty well.
I already have hald/dbus running. After I adjust fstab to mount /proc I reboot and see marco no longer core dump. But gnome-keyring-daemon is still constantly give a core file roughly 10mb in size.

I don't run Marco on Windows and don't think it's even possible. I know there's some efforts to make KDE runs on Windows but don't hear anything about the GTK based ones.

LXDE gives me screen tearing even on Lubuntu. So I try to avoid it. It's so linuxism that it can't be run correctly on NetBSD. Don't know about the state of it on FreeBSD. But in this regards, Mate or XFCE is far more portable than LXDE.

I'm a young guy that never use KDE 3.5 but I've some experience with TDE (a fork of it) on Q4OS. I would say out of the box it's ugly but after some tweaking it just works and resembles WinXP. The most important thing is to replace konsole and kate/kwrite with alternative GTK based like LXTerminal, Mousepad because their version are ancient and have no proper unicode support so can't display unicode characters correctly. Anyway, TDE is being ported to FreeBSD but very slowly. I think it doesn't worth to try when I could stick with far better option like Mate or XFCE.
 
In rc.conf set
Code:
dumpdev="NO"



Of course you should not do this when you get frequent crash dumps just to make the symptom go away. You need to find the reason for the crash dumps and fix it.

If you allocate a too small memory for VMs you may see crashs.
Oh I remember this dumpdev was enabled by default on the installer on the hardening section. I didn't notice about it much because this section is something new, I've not installed a FreeBSD system since version 9 so I just hit Enter :)

I has 8G ram on the host and give 4G for the VM and 4 cpu cores for it. That's the maximum I could give otherwise the host will crash. Is 4G just too little for a Root On ZFS installation? My CPU only has 4 physical cores and 8 threads and I give all 4 cores for the FreeBSD VM.
 
Firefox.core is nearly 200mb and the later both nearly 10mb (this time).

Interesting. I'm just now looking at a firefox core dump of 7992414208 bytes. For some reason that's a little bit larger than yours. ;) In any case, I like to see the .core files, even just because because the time and date on them is meaningful to me.
 
Interesting. I'm just now looking at a firefox core dump of 7992414208 bytes. For some reason that's a little bit larger than yours. ;) In any case, I like to see the .core files, even just because because the time and date on them is meaningful to me.
Oh .core file are crazy. I used to get 1.2g .core file from eclipse on OpenIndiana. The last version for Solaris 10 is 4.6.3 and it's crash even before the progress bar start :p
 
Don't know about the state of it on FreeBSD. But in this regards, Mate or XFCE is far more portable than LXDE.
Well thats the thing, LXDE is actually just a collection of individual packages with the main two being:

OpenBox (Very portable)
PCManFM (again very portable)

You might want to look at solving the tearing issue in the xorg.conf.d system; a non-compositing windows manager like OpenBox shouldn't really deal with this.

Oh yeah, as for Firefox, mine often core dumps. Both ESR and normal. On OpenBSD I can solve this by raising ulimits but that same fix (or issue) doesn't seem to be the same on FreeBSD. I generally moved to Iridium (for another reason) and stopped looking into it.
 
Well thats the thing, LXDE is actually just a collection of individual packages with the main two being:

OpenBox (Very portable)
PCManFM (again very portable)

You might want to look at solving the tearing issue in the xorg.conf.d system; a non-compositing windows manager like OpenBox shouldn't really deal with this.

Oh yeah, as for Firefox, mine often core dumps. Both ESR and normal. On OpenBSD I can solve this by raising ulimits but that same fix (or issue) doesn't seem to be the same on FreeBSD. I generally moved to Iridium (for another reason) and stopped looking into it.
I used PCManFM with Fluxbox for a time :) No, I don't think it's xorg. The same xorg with xfce, no tearing at all :p
 
No, I don't think it's xorg. The same xorg with xfce, no tearing at all :p
From Xfwm 4.12 onward, the compositor is enabled by default so that is why you don't see tearing with your default Xorg.

Basically if you are not using a compositing Window Manager (i.e not Xfwm) then I do think you need to set something in the xorg.conf; such as

Code:
Section "Device"
  Identifier  "Intel Graphics"
  Driver      "intel"
  Option      "TearFree" "true"
EndSection
 
From Xfwm 4.12 onward, the compositor is enabled by default so that is why you don't see tearing with your default Xorg.

Basically if you are not using a compositing Window Manager (i.e not Xfwm) then I do think you need to set something in the xorg.conf; such as

Code:
Section "Device"
  Identifier  "Intel Graphics"
  Driver      "intel"
  Option      "TearFree" "true"
EndSection
Oh thanks, I don't know about this :)
 
Status
Not open for further replies.
Back
Top