Does anyone has any idea why Simple Login Manager [SLiM] is constantly dropping coredumps [slim.core] no matter OBSD version it is running on?
This is quite irritating and I haven't found any answer yet.
I'd like to be able to turn this thing off, but 'ulimit -c 0' doesn't seem to change anything.

Because the filesystem layouts between Linux & OpenBSD are different, you may find code which expects to read/write to a nonexistent location. More information can be found in hier(7) when comparing to information for Linux.

Unless you just happen to run into someone who has ported this application to OpenBSD, I suspect no one will have the specific answer you are hoping to get. In general, porting issues result from:

filesystem differences.

libraries found in Linux, but not in OpenBSD.

differences in the libraries (versions) themselves.

You should also study the compat_linux(8) manpage for additional information.

SLiM is actually available in OpenBSD ports/packages system [slim, slim-themes]. I have linux_compat disabled and I am not using an emulation of any sort.
I have also contacted maintainer of this port, but I haven't got a reply yet.
I can paste bin attachment of slim.core if needed.

Your core file was created from an executable containing debugging symbols. That requires manually building the port/package with debugging symbols turned on.

The executable binary file(s), with symbols, is/are made available, also.

Core files are best used on the failing system with gdb(1), to produce backtraces for root cause analysis.

Since the normal package build process strips symbols from executables, it will make your use of an existing core file difficult. I know I've built ports with symbols in the past, but I no longer remember how to do so. I might have set an environment variable or modified the Makefile.

Depending on your debugging and *nix skills, you may consider rebuilding the port with symbols in order to be able to conduct a root cause analysis.

If you don't hear from the port maintainer within the next several days, consider posting a more complete problem report to the ports@ mailing list. You'll need to include a dmesg, SLiM configuration file content, and any other relevant information.

I went through the aboves [more or less - I am not a coder, but I tried to stick with method, although I had to copy the results manually] and I have some results. I am posting them as the attachments.

Looking through your painstakingly hand-crafted gdb output, here is what I see:

The abort of the application was caused by the attempt to release some memory that was already released. (#2 in the back trace).

X11 services are heavily involved. The last obvious call in use was for _X11TransFreeConnInfo, which is in libX11, after coming from _XDisconnectDisplay.

I do not see any symbols that refer to individual source code lines in your SLiM executable, and I see many lines that say "No symbol table info available." This tells me there is a problem with symbols, but where, I cannot tell from the abbreviated content you were able to capture by hand.

I downloaded your tarball, but it contains only the .core file, and that is useless to me, for all the reasons I stated in my first post: I need to have an exact matching OS release/flavor/architecture, and I must have the executable. But, seeing as how the executable does not appear to have the appropriate/complete symbols within it, I don't know if it would be of any help.

I discussed the problem with the maintainer of the port [btw - the maintainer has changed recently] and we seemed to agree, that the whole thing was xfsm-shutdown-helper of xfce4 which didn't allow SLiM to end its session in a clean way, so SLiM generated a coredump. He also forwarded the problem to the new maintainer, so - hopefuly - we'll get a fix soon.
As of my box: I've managed to fix the problem in a very dirty way - little 'hack' performed with the hex editor did the trick for me - at least before the new version comes up.