bug in inets or erlang!

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

bug in inets or erlang!

Michał Ptaszek

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)


Reply | Threaded
Open this post in threaded view
|

bug in inets or erlang!

Matthias Lang-2
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)


Reply | Threaded
Open this post in threaded view
|

bug in inets or erlang!

Michał Ptaszek
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)
>
>  
>



Reply | Threaded
Open this post in threaded view
|

bug in inets or erlang!

Micael Karlberg-4
Hi,

The inets web-server get's the (modification) time from the file-info
record of the file: file:read_file_info(Path). What does this call
give you?

/BMK

Peter Lund wrote:

> 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)
>>
>>  
>>
>
>


Reply | Threaded
Open this post in threaded view
|

bug in inets or erlang!

Matthias Lang-2
In reply to this post by Michał Ptaszek
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!

Finite limits in time representations are a fact of life in popular
operating systems, so there's always going to be a value that's just
one incy-wincy-teeny-weeny second on the wrong side of the
limit. Erlang just happens to have chosen an 'interesting' limit.

I don't recall ever seeing a bignum time representation in Erlang,
though there's bound to be a LISP one.

 > I am running on R10B (5.4.8). How do you figure out which "R10B-NN" it is?

The only way I know of is to remember which file you downloaded. I
don't think the system keeps track of the patch level.

 > 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.

"some OTP person". I guess that's slightly better than being a piece
of "human capital". If you're lucky, someone might help you debug the
problem---there are still a few steps to making it easily reproduceable.

Matthias


Reply | Threaded
Open this post in threaded view
|

bug in inets or erlang!

Michał Ptaszek
In reply to this post by Micael Karlberg-4

> Micael Karlberg wrote: Hi,
>
> The inets web-server get's the (modification) time from the file-info
> record of the file: file:read_file_info(Path). What does this call
> give you?
>
> /BMK


Nothing unusual sorry!  I got this:

(pds)6> file:read_file_info("index.html").
{ok,{file_info,360,
               regular,
               read_write,
               {{2005,11,29},{12,15,18}},
               {{2005,10,17},{18,44,2}},
               {{2005,10,17},{18,44,2}},
               33188,
               1,
               1042,
               1723200,
               426909,
               1001,
               1001}}
(pds)7>

As Mattias said. This may be difficult to reproduce. I don't know what
caused inets to make that failing call (except for what I see in the
stack trace I posted originally). I have only seen it once and that was
after a brute force power down of the FreeBSD system (removal of
electrical power) and then turning it on again some 4-5 hours later.

/Peter

> Peter Lund wrote:
>
>> 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)
>>>
>>>  
>>>
>>
>>
>



Reply | Threaded
Open this post in threaded view
|

bug in inets or erlang!

Micael Karlberg-4
It's not an unusual call. It does this every time it sends
a reply to a request (if you have the mod_get module). The
thing is that for some reason the file_info record returned
by file:read_file_info(Path) had a strange mdate
(modification date).
I will look into this some more tomorrow.

/BMK

Peter Lund wrote:

>
>> Micael Karlberg wrote: Hi,
>>
>> The inets web-server get's the (modification) time from the file-info
>> record of the file: file:read_file_info(Path). What does this call
>> give you?
>>
>> /BMK
>
>
>
> Nothing unusual sorry!  I got this:
>
> (pds)6> file:read_file_info("index.html").
> {ok,{file_info,360,
>               regular,
>               read_write,
>               {{2005,11,29},{12,15,18}},
>               {{2005,10,17},{18,44,2}},
>               {{2005,10,17},{18,44,2}},
>               33188,
>               1,
>               1042,
>               1723200,
>               426909,
>               1001,
>               1001}}
> (pds)7>
>
> As Mattias said. This may be difficult to reproduce. I don't know what
> caused inets to make that failing call (except for what I see in the
> stack trace I posted originally). I have only seen it once and that was
> after a brute force power down of the FreeBSD system (removal of
> electrical power) and then turning it on again some 4-5 hours later.
>
> /Peter
>
>> Peter Lund wrote:
>>
>>> 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)
>>>>
>>>>  
>>>>
>>>
>>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

bug in inets or erlang!

Claes Wikström
In reply to this post by Michał Ptaszek
Peter Lund wrote:
> 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 do :-)

/klacke


Reply | Threaded
Open this post in threaded view
|

bug in inets or erlang!

Peter Lund
Good you have an opionion. Please enlight us!

I think it is a bug! There is no real reason why this tiny function
should be causing crashes even if the caller asks for a valid time and
date, any year in the past, for instance the birth of planet earth year
some -6 billion or something...

/Peter

Claes Wikstrom wrote:

> Peter Lund wrote:
>
>> 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 do :-)
>
> /klacke
>


Reply | Threaded
Open this post in threaded view
|

bug in inets or erlang!

Michał Ptaszek
In reply to this post by Claes Wikström
Good you have an opionion. Please enlight us!

I think it is a bug! There is no real reason why this tiny function
should be causing crashes even if the caller asks for a valid time and
date, any year in the past, for instance the birth of planet earth
year some -6 billion or something...

/Peter

Claes Wikstrom wrote:

> Peter Lund wrote:
>
>> 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 do :-)
>
> /klacke
>




Reply | Threaded
Open this post in threaded view
|

bug in inets or erlang!

Matthias Lang-2
In reply to this post by Peter Lund

 > >>  erlang:universaltime_to_localtime({{1969,12,31},{23,59,59}}).

Peter Lund writes:
 > I think it is a bug! There is no real reason why this tiny function
 > should be causing crashes even if the caller asks for a valid time and
 > date, any year in the past, for instance the birth of planet earth year
 > some -6 billion or something...

I don't think anyone is disputing that inets crashing is a bug. There
are varying opinions over how important it is and who should fix it.
I'm not sure the "squeaky hinge" approach is the best.

Making universaltime_to_localtime work for all possible dates in the
past and future is nontrivial. Take a look at

  http://www.twinsun.com/tz/tz-link.htm
  http://www.tondering.dk/claus/cal/calendar27.txt

Matthias


Reply | Threaded
Open this post in threaded view
|

bug in inets or erlang!

Bengt Kleberg-4
On 2005-11-30 10:20, Matthias Lang wrote:

> Making universaltime_to_localtime work for all possible dates in the
> past and future is nontrivial.

making universaltime_to_localtime work according to the documentation is
almost trivial. it says:

''Converts Universal Time Coordinated (UTC) date and time to local
               date and time, if this is supported by the underlying OS.
Other-
               wise, no conversion is done, and {Date1, Time1} is
returned.''


i.e. if the conversion fails, just return the input.


bengt


Reply | Threaded
Open this post in threaded view
|

bug in inets or erlang!

Raimo Niskanen-3
In reply to this post by Michał Ptaszek
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 (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


Reply | Threaded
Open this post in threaded view
|

bug in inets or erlang!

Raimo Niskanen-3
In reply to this post by Bengt Kleberg-4
It also says:

        Failure: badarg if Date1 or Time1 do not denote a valid
        date or time.

Unfortunately it does not say what is a valid date or time.



bengt.kleberg (Bengt Kleberg) writes:

> On 2005-11-30 10:20, Matthias Lang wrote:
>
> > Making universaltime_to_localtime work for all possible dates in the
> > past and future is nontrivial.
>
> making universaltime_to_localtime work according to the documentation
> is almost trivial. it says:
>
> ''Converts Universal Time Coordinated (UTC) date and time to local
>                date and time, if this is supported by the underlying
> OS. Other-
>                wise, no conversion is done, and {Date1, Time1} is
> returned.''
>
>
> i.e. if the conversion fails, just return the input.
>
>
> bengt

--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB


Reply | Threaded
Open this post in threaded view
|

bug in inets or erlang!

Matthias Lang-2
In reply to this post by Bengt Kleberg-4

I think you're interpreting the manual in a way which wasn't intended
by the author. I read it to mean

  If the underlying OS doesn't support UTC->localtime, return the
  the original arguments.

  If the conversion can't be done for some other reason, exit(badarg).

Matthias

Bengt Kleberg writes:
 > On 2005-11-30 10:20, Matthias Lang wrote:
 >
 > > Making universaltime_to_localtime work for all possible dates in the
 > > past and future is nontrivial.
 >
 > making universaltime_to_localtime work according to the documentation is
 > almost trivial. it says:
 >
 > ''Converts Universal Time Coordinated (UTC) date and time to local
 >                date and time, if this is supported by the underlying OS.
 > Other-
 >                wise, no conversion is done, and {Date1, Time1} is
 > returned.''
 >
 >
 > i.e. if the conversion fails, just return the input.
 >
 >
 > bengt