bug in inets or erlang!

[Raimo Niskanen]

We intend to fix this problem in a later release of R10B.

The problem is most probably that the stat() call done by
file:read_file_info/1 returns -1 in the modification time
field for some strange situation in your FreeBSD box.
That will we fix by returning a #file_info.mtime value
of 'undefined'. The inets application will also be fixed
to handle the new field value. Other applications
using the mtime field be warned!

Oh, and you are running R10B-6 (erts-5.4.8). The erts
revision number is the more interesting to us "OTP people".

I think erlang:universaltime_to_localtime/1 should crash for
a date before the start of the Unix EPOCH. It checks its fields
for any value that might upset mktime() on any Unix. The 
question is if calendar:universal_time_to_local_time/1 could
do anything better, but it is actually documented to not
accept dates before Jan 1 1970. For such calculations
there are the gregorian time functions in the calendar module.
The invalid date should not have been generated at all.


erlang@REDACTED (Peter Lund) writes:

> Yes, the important question here is if:
> 
>   erlang:universaltime_to_localtime({{1969,12,31},{23,59,59}}).
> 
> really should crash the code just because it is 1 sec too early? No-one seems to have any opinion about it!
> 
> I am running on R10B (5.4.8). How do you figure out which "R10B-NN" it is?
> 
> 
> Regarding why inets made this call when I tried to surf to "/" on my server I do not know. I hoped that some OTP person should fix this. The index.html on the DocumentRoot place was not even close to 36 years old (just a couple of months).
> 
> /Peter
> 
> Matthias Lang wrote:
> 
> >Hi,
> >
> >I started off by wondering why universaltime_to_localtime() doesn't
> >work for the date you gave. The relevant files are
> > erts/emulator/beam/bif.c and erts/emulator/beam/erl_time_sup.c. In
> > univ_to_local(), there's a rangecheck on the year. If it's less than
> >BASEYEAR, the call fails. BASEYEAR is 1970. Real men don't read
> >manuals, but it'd help all the sissies like me if the manual gave a
> >clue about that.
> >
> >The other question is easier to answer---your trace provides all the
> >information. inets calls univeraltime_to_localtime/1 with an argument
> > from 1969 because the file you tried to get inets to serve has a
> > modification time from 1969. Take a look at the log to see which file
> >it was.
> >
> >Matthias
> >
> >----------------------------------------------------------------------
> >
> >peter writes:
> >
> > > After my FreeBSD server running erlang was restarted, suddenly
> > > INETS was not comming up as it was expected to. In the inets
> > > error_log I found:
> > > > > more error_log_16111
> > > [26/Nov/2005:13:14:42 -0000] reporting error: traverse exit from apply: mod_get:
> > > do =>
> > > {badarg,[{erlang,universaltime_to_localtime,[{{1969,12,31},{23,59,59}}]},
> > >          {calendar,local_time_to_universal_time_dst,1},
> > >          {httpd_util,rfc1123_date,1},
> > >          {mod_get,get_modification_date,1},
> > >          {mod_get,do_get,1},
> > >          {httpd_response,traverse_modules,2},
> > >          {httpd_response,generate_and_send_response,1},
> > >          {httpd_request_handler,respond,3}]}
> > > > > WHY is inets calling erlang:universaltime_to_localtime/1 with
> > [{{1969,12,31},{23,59,59}}] ?? Looks like a potential bugg to me OR
> > should this bug actually be located to the erlang module instead?
> > Should this call really result in a crach?
> > > > Anyhow to get inets up and running again I had to patch the
> > calendar.erl module catching for this crash and in that case return
> > {{1970,1,1},{0,0,0}}. > > What need to change here erlang or some
> > module in inets?
> > > > /PeterPeter Lund
> > > _________________________________________________________
> > > Sent using Mail2Forum (http://m2f.sourceforge.net)
> >
> >
> 

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB