# Life without core dump, is it possible?



## badbrain (Jul 12, 2019)

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


----------



## Crivens (Jul 12, 2019)

How about running a memory tester? Absence of core dumps does not mean nothing is wrong.


----------



## badbrain (Jul 12, 2019)

Crivens said:


> 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.


----------



## badbrain (Jul 12, 2019)

Firefox also core dump but usable. I'm posting using it now. Not as bad as DragonFlyBSD.


----------



## badbrain (Jul 12, 2019)

Back to Windows. I don't know how to deal with .core file. Here is the list of them: 






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.


----------



## Crivens (Jul 12, 2019)

`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.


----------



## badbrain (Jul 12, 2019)

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.


----------



## badbrain (Jul 12, 2019)

Crivens said:


> `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


----------



## Nicola Mingotti (Jul 12, 2019)

maybe you are looking for this:
----- /etc/sysctl.conf -----
kern.corefile=/dev/null
----------------------------


----------



## badbrain (Jul 12, 2019)

Nicola Mingotti said:


> 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.


----------



## Nicola Mingotti (Jul 12, 2019)

badbrain said:


> 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.


AFAIK all core dumps will go to /dev/null. no exceptions.


----------



## kpedersen (Jul 12, 2019)

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).



badbrain said:


> 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.


----------



## badbrain (Jul 13, 2019)

kpedersen said:


> 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).
> 
> ...


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.


----------



## badbrain (Jul 13, 2019)

getopt said:


> In rc.conf set
> 
> ```
> dumpdev="NO"
> ...


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.


----------



## Deleted member 9563 (Jul 13, 2019)

badbrain said:


> 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.


----------



## badbrain (Jul 13, 2019)

OJ said:


> 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


----------



## facedebouc (Jul 13, 2019)

You can add this statement in your ~/.login_conf:
`:coredumpsize=0:`


----------



## kpedersen (Jul 13, 2019)

badbrain said:


> 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.


----------



## badbrain (Jul 14, 2019)

kpedersen said:


> 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)
> ...


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


----------



## kpedersen (Jul 14, 2019)

badbrain said:


> No, I don't think it's xorg. The same xorg with xfce, no tearing at all


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 


```
Section "Device"
  Identifier  "Intel Graphics"
  Driver      "intel"
  Option      "TearFree" "true"
EndSection
```


----------



## badbrain (Jul 14, 2019)

kpedersen said:


> 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
> 
> ...


Oh thanks, I don't know about this


----------

