Core dump on SmartOS joyent_20150320T005835Z

[pannon]

Successfully compiles on SmartOS but core dumps when running date.

Extracted a core stack with mdb please see below if this is of any help.
If required can also provide the full coredump file.

Release is: joyent_20150320T005835Z

ffffdf7fffdfef70 libc.so.1`_lwp_kill+0xa()
ffffdf7fffdfefa0 libc.so.1`raise+0x20(6)
ffffdf7fffdfefb0 libumem.so.1`umem_do_abort+0x44()
ffffdf7fffdff0b0 0xffffdf7ffec37fb2()
ffffdf7fffdff140 0xffffdf7ffec40b28()
ffffdf7fffdff180 libumem.so.1`umem_alloc_retry+0xc0(ffffdf7ffec6a180, 0)
ffffdf7fffdff1e0 libumem.so.1`umem_alloc+0x9b(120, 0)
ffffdf7fffdff210 libumem.so.1`umem_malloc+0x3f(110)
ffffdf7fffdff240 libumem.so.1`calloc+0x60(22, 8)
ffffdf7fffdff280 libgcc_s.so.1`__emutls_get_address+0x10e()
ffffdf7fffdff2b0 libfaketimeMT.so.1`gettimeofday+0x4f()
ffffdf7fffdff340 libumem.so.1`umem_init+0x4b4()
ffffdf7fffdff380 libumem.so.1`umem_alloc_retry+0xc0(ffffdf7ffec6a180, 0)
ffffdf7fffdff3e0 libumem.so.1`umem_alloc+0x9b(120, 0)
ffffdf7fffdff410 libumem.so.1`umem_malloc+0x3f(110)
ffffdf7fffdff440 libumem.so.1`calloc+0x60(22, 8)
ffffdf7fffdff480 libgcc_s.so.1`__emutls_get_address+0x10e()
ffffdf7fffdff4b0 libfaketimeMT.so.1`system_time_from_system+0x18()
ffffdf7fffdff580 libfaketimeMT.so.1`ftpl_init+0x922()
ffffdf7fffdff5a0 0xffffdf7fe9b47b66()
ffffdf7fffdff5b0 libfaketimeMT.so.1`_init+0xe()
ffffdf7fffdff630 ld.so.1`call_init+0x117(ffffdf7fff340db0, 1)
ffffdf7fffdff970 ld.so.1`setup+0xdb8(ffffdf7fffdffb38, ffffdf7fffdffc08, 0, ffffdf7fffdfffcd, 1000, 
ffffdf7fff3abd0e)
ffffdf7fffdffa90 ld.so.1`_setup+0x282(ffffdf7fffdffaa0, 190)
ffffdf7fffdffb20 ld.so.1`_rt_boot+0x6c()
0000000000000001 0xffffdf7fffdffcf8()

[pannon]

Also should add to this that I am keen to test or provide anything required.

[rbalint]

It looks something surprising in one of the following calls. Could you please try them on SmartOS?
clock_gettime(CLOCK_REALTIME, &result);
clock_gettime(CLOCK_MONOTONIC, &result);
clock_gettime(CLOCK_MONOTONIC_RAW, &result);

This function works OK on other platforms AFAIK:
ffffdf7fffdff4b0 libfaketimeMT.so.1`system_time_from_system+0x18()
, but it looks like clock_gettime() is failing for you with memory allocation error.

[pannon]

@rbalint there seem to be no CLOCK_MONOTONIC_RAW in Illumos http://illumos.org/man/3HEAD/time.h

[rbalint]

Please try this PR: #69

[pannon]

Seems that this issue is more sinister, still core dumping (dump looks the same). I can give you access to an instance to test this if you OK with that.

[pannon]

Just a quick one, the 32bit version of libfaketimeMT.so.1 is working fine with 32 bit apps. The 64bit version is affected only.

[rbalint]

...
ffffdf7fffdff280 libgcc_s.so.1__emutls_get_address+0x10e() ffffdf7fffdff2b0 libfaketimeMT.so.1gettimeofday+0x4f()
ffffdf7fffdff340 libumem.so.1umem_init+0x4b4() ffffdf7fffdff380 libumem.so.1umem_alloc_retry+0xc0(ffffdf7ffec6a180, 0)
ffffdf7fffdff3e0 libumem.so.1umem_alloc+0x9b(120, 0) ffffdf7fffdff410 libumem.so.1umem_malloc+0x3f(110)
ffffdf7fffdff440 libumem.so.1calloc+0x60(22, 8) ffffdf7fffdff480 libgcc_s.so.1__emutls_get_address+0x10e()
ffffdf7fffdff4b0 libfaketimeMT.so.1`system_time_from_system+0x18()
...
It looks like the libgcc TLS implementation calls gettimeofday() on this platform and I see no workaround to fix that in libfaketime. I think single-threaded applications would work and maybe if you use a newer GCC/other compiler with different TLS implementation that could work as well..

[pannon]

Tried with a newer GCC 4.9 same results.

In a nutshell:

• 32 bit apps work with the 32 bit libfaketimeMT.so
• 64 bit apps core dump with 64 bit libfaketimeMT.so

Must be a 64 bit specific issue triggering this problem.

[pannon]

Just a heads up, this is indeed a GCC issue there is an open issue for this now here: TritonDataCenter/pkgsrc#264

Feel free to close this one.