2

Have a bit of trouble tracking down the cause of this.

Here is the code bit:

    #include <time.h>
time_t now;
struct tm *mytime;
char yyyy[5];
char mm[3];
char dd[3];
char mname[10];
if(time(&now)!=(time_t)(-1))
{
    mytime=localtime(&now);
    strftime(yyyy, sizeof(yyyy), "%Y", mytime);
    strftime(mm, sizeof(mm), "%m", mytime);
    strftime(dd, sizeof(dd), "%d", mytime);
    strftime(mname, sizeof(mname), "%B", mytime);
}

It crashes on localtime line:

Segmentation fault (core dumped)

Any ideas?

Mannix
  • 411
  • 10
  • 23
  • 1
    Same here. No core dump on my box (gcc 4.8.1/glibc 2.17 on Lubuntu 13.10). – Mike Holt Mar 19 '14 at 22:08
  • 1
    What is the evidence that is crashed on `localtime()`? – chux - Reinstate Monica Mar 19 '14 at 22:29
  • 1
    The evidence is I put in some `printf` statements to isolate the line in the code which caused the fault. – Mannix Mar 20 '14 at 00:45
  • 1) Rather than discuss the evidence, post it: the code used and the corresponding output. When `printf()` are added, faults could arise due to the `printf()`. 2) Consider `struct tm mytime; mytime = *localtime(&now); if (0==strftime(yyyy, sizeof(yyyy), "%Y", &mytime)) Handle_Error();` – chux - Reinstate Monica Mar 20 '14 at 15:16

2 Answers2

1

The sample code runs fine for me. Post your full code? Or cut down your example to minimal possible which still reproduces problem. And run gdb on your core 'gdb -c a.core a.out' and get a backtrace(bt).

One gotcha with localtime is the returned pointer is a pointer to a static global var and subsequent calls to localtime update the var. Tripped me up once long long ago.

struct tm *localtime(const time_t *time)

The return value is a pointer to a static broken-down time structure, which might be overwritten by subsequent calls to any of the date and time functions. (But no other library function overwrites the contents of this object.)

From: http://www.chemie.fu-berlin.de/chemnet/use/info/libc/libc_17.html

On searching for core files:

See also core dumped - but core file is not in current directory?

Make sure system can write core file.
* for me on one sample ununtu system ulimit -c showed 0 *

ulimit -c unlimited

Check what pattern used and change the pattern to a simple one or different location.

cat /proc/sys/kernel/core_pattern
#sysctl -w kernel.core_pattern=core

Search some common locations and look in /var/log/messages:

ls /var/crash /var/cache/abrt /var/spool/abrt/ /tmp/*core*
tail /var/log/messages

On ubuntu examine the apport service config and init/rcfiles:

find /etc/ |grep appo
Community
  • 1
  • 1
gaoithe
  • 4,218
  • 3
  • 30
  • 38
  • Although it said it produced a core file, the core file is not there. Which compiler flags do I need such that it will produce a core file with useful data? – Mannix Mar 19 '14 at 22:28
  • Compiler doesn't control core file production or location. It is a system setting. Are you on linux? What flavour of os and version are you using? – gaoithe Mar 19 '14 at 22:39
  • Look in /var/crash or /var/cache/abrt or. /var/spool/abrt/ or other depending on your system config. See also http://stackoverflow.com/questions/2065912/core-dumped-but-core-file-is-not-in-current-directory – gaoithe Mar 19 '14 at 23:02
  • 1
    No, it's not in any of those directories. $ uname -a Linux marple.physast 3.2.0-60-generic #91-Ubuntu SMP Wed Feb 19 03:54:44 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux – Mannix Mar 20 '14 at 00:30
  • Hmm. Ubuntu. Grep for corefiles config in /etc and in kernel. Maybe start with `find /etc -name "*core*"` and `find /etc -type f -exec grep core {} +`. Look inside files found. Any clue there to location or name? Also check your `ulimit -c` as in other stackoverflow question. – gaoithe Mar 20 '14 at 03:12
  • Look for core pattern in kernel. `cat /proc/sys/kernel/core_pattern` any corefiles lying around matching that pattern? Before you run your prog which crashes change the pattern to a simple one: `sysctl -w kernel.core_pattern=core`. That might override kernel pattern and get core dumps generated in current dir. – gaoithe Mar 20 '14 at 03:22
1

This may or may not be something close to your problem? Still don't quite have enough info to be sure what you are doing. I'd be thinking localtime is not the problem but somewhere in the printfs there are problems . . .

How are you compiling your project? g++ or gcc?

Can you print a string?? (as opposed to string ptr) What is a string in your context?

1 problem here:

fprintf(stdout,"# Single electron capture cross sections, %s state-selective\n",res);

If string is typedef a char[] then passing a pointer to it in func args would be better?

Compiling your sample making some assumptions and adding debug (-g3):

gcc -g3 stackoverflow_localtime_crash.c -o socrash

./socrash 

# Single electron capture cross sections, RESSTRING state-selective
# Magic number=20032014, 20 March 2014, 
# Single electron capture cross sections, RESSTRING state-selective
# ^0+ +  -> ^-1+ + ^+
# Method=MCLZ
#  et al. 2014, to be submitted
# ----------------------------------------------------------------------------
# Energy        Cross sections (10^-16 cm^2)
# (eV/u)        LABELSTRING                     �H���u�j 

* lots more JUNK follows res string itself cannot be passed in on stack and printed *

Segmentation fault (core dumped)

gdb -c core socrash 

Core was generated by `./socrash'.
Program terminated with signal 11, Segmentation fault.
[New process 10298]
#0  0xb770e713 in strlen () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0xb770e713 in strlen () from /lib/tls/i686/cmov/libc.so.6
#1  0xb76da6d9 in vfprintf () from /lib/tls/i686/cmov/libc.so.6
#2  0xb76e0b9f in fprintf () from /lib/tls/i686/cmov/libc.so.6
#3  0x08048a42 in prtcsheader (cs=0xbf9e907c, labels=0xbf9e90bc, res=0xbf9e90a8 "RESSTRING") at stackoverflow_localtime_crash.c:66
#4  0x08048b36 in main (argc=Cannot access memory at address 0x0
) at stackoverflow_localtime_crash.c:80
(gdb) list
64      fprintf(stdout,"%-15s","# (eV/u)");
65      for(i=0;labels[i]!=NULL;i++)
66          fprintf(stdout,"\t%-14s",labels[i]);
67      fprintf(stdout,"\t%-14s","Total");
68  
69  return 0;
(gdb) 

* see line 66 there is also a problem * might well be the way I have have declared string :-P

66          fprintf(stdout,"\t%-14s",labels[i]);

* If you can find a core file yourself then it would be a big help!!! *

If you can't find core then maybe you could use ltrace. Run strace to get trace of all system calls a process does. Run ltrace to get trace of all lib calls a process does.

Try:

strace ls

ltrace ls

On my crashing example:

ltrace ./socrash 1>stdout.log 2>socrash_ltrace.log
less socrash_ltrace.log 
gaoithe
  • 4,218
  • 3
  • 30
  • 38
  • `string` is `char *` $ gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Compiler options: -Wall -std=gnu99 – Mannix Mar 21 '14 at 02:32
  • `labels` is a NULL-terminated array of strings, i.e., `char **`. So `labels` is `string *`, or `char **`. But, as I have said before, it's crashing on the `localtime()` call. I put a bunch of printf statements in the code in order to isolate which line was resulting in the segmentation fault. It was `localtime()`. – Mannix Mar 21 '14 at 02:38
  • Given all the info the calls to localtime() all look okay. printfs behaviour near seg fault might not give you the failing place. All that printf puts in output buffer might not get seen. Or something bad but subtle happens leading to seg fault a bit later in code. Had you a \n at end of all your debug printfs? You don't have multiple threads, do you? We don't have exact info to go on, that is why we are suspicious it is not localtime. Have you tried ltrace? Did you check what ulimit -c shows? Find core? Adding debug options at compile time makes core more useful. – gaoithe Mar 21 '14 at 08:51