Xref: utzoo comp.os.vms:39689 comp.lang.c:39957
Newsgroups: comp.os.vms,comp.lang.c
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Subject: Re: WHY is this crashing???!!!
Message-ID: <1991Jun11.051339.26871@thunder.mcrcim.mcgill.edu>
Organization: McGill Research Centre for Intelligent Machines
References: <6246@mahendo.Jpl.Nasa.Gov>
Date: Tue, 11 Jun 91 05:13:39 GMT
Lines: 38

In article <6246@mahendo.Jpl.Nasa.Gov>, robert@triton.jpl.nasa.gov (Robert Angelino) writes:

> I have this code that keeps going out to lunch.

[...code which doesn't mention `date' anywhere...]
>         date->tm_year = atoi(ptr);

> It CRASHES at the "atoi" call.

I think it far likelier that the atoi call works perfectly well and the
assignment fails, probably because date is a null pointer.

> This is the output I get from the run:

> %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00000014, PC=0000D8D9, PSL=03C00000
> %TRACE-F-TRACEBACK, symbolic stack dump follows
[...]

This makes it even more likely.  The virtual address given is 0x14,
which is precisely what you'd see for the tm_year member of a null
pointer to struct tm.  (The tm_year is the 6th int in the structure on
most machines, and on a VAX that normally translates into an offset of
0x14 from the beginning of the structure.)

> I've tried the following and it still crashes:

>   cur_time[11] = '\0';
>   ptr = cur_time + 7;
>   date->tm_year = atoi((const char*) ptr);

I imagine date is still a null pointer; if so, diddling with atoi won't
do squat.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu