# PHP 5.1.2 segfaults in get_timezone_info

- Thread: https://externals.io/message/22497
- Original archive: https://news-web.php.net/php.internals/22497
- Started by Al Baker on 2006-03-17T07:28:13+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #22497 — Al Baker — 2006-03-17T07:28:13+00:00

URL: https://externals.io/message/22497#22497

Hi,

We're trying to run php 5.1.2 on Windriver Linux (PPC) -- unsupported I
know -- and most things appear to be working.  However when trying to
use Smarty (which has calls to date functions for caching), PHP
segfaults in `time()`.

Running PHP in GDB shows the trace of failing in memcpy and malloc as
called from timelib_parse_tzfile (timezone=0x30029008 "",
tzdb=0x179018c) at ... ext/date/lib/parse_tz.c:91

The rest of the stack is full of calls to ext/date/php_date.c:319 and
gdb eventually says Previous frame inner to this frame (corrupt stack?)

Looking at strace, Smarty_Compiler.class.php goes through and eventually
does time(NULL) = 138027 a couple times and then mmap(NULL, 100667392,
PROT_READ|PROT_WRITE, MAP_PRIVATE,MAP_ANONYMOUS, -1, 0) = 0x30029000
followed by the `SIGSEGV` @ 0.

Setting date.timezone in php.ini doesn't solve the problem.  WindRiver
keeps its timezone files in /usr/share/zoneinfo
(e.g. /usr/share/zoneinfo/GMT).  There is also a localtime time zone
file in /etc.

I don't know if this is a php bug, or perhaps pilot-error on my part on
either WindRiver Linux configuration or cross-compiling PHP. 

Thanks,
Al

---

## #22498 — Al Baker — 2006-03-17T07:38:57+00:00

URL: https://externals.io/message/22497#22498 · In reply to: #22497

Ok, I'm not sure what /etc/localtime was but when I copied
over /usr/share/zoneinfo/America/New_York to /etc/localtime the problem
went away and things are working gloriously-well.

Perhaps just a note for the future that if somehow the OS didn't setup
the timezone properly, PHP should default to something rather than
segfaulting.

Regards,
Al


> Hi,
> 
> We're trying to run php 5.1.2 on Windriver Linux (PPC) -- unsupported I
> know -- and most things appear to be working.  However when trying to
> use Smarty (which has calls to date functions for caching), PHP
> segfaults in `time()`.
> 
> Running PHP in GDB shows the trace of failing in memcpy and malloc as
> called from timelib_parse_tzfile (timezone=0x30029008 "",
> tzdb=0x179018c) at ... ext/date/lib/parse_tz.c:91
> 
> The rest of the stack is full of calls to ext/date/php_date.c:319 and
> gdb eventually says Previous frame inner to this frame (corrupt stack?)
> 
> Looking at strace, Smarty_Compiler.class.php goes through and eventually
> does time(NULL) = 138027 a couple times and then mmap(NULL, 100667392,
> PROT_READ|PROT_WRITE, MAP_PRIVATE,MAP_ANONYMOUS, -1, 0) = 0x30029000
> followed by the `SIGSEGV` @ 0.
> 
> Setting date.timezone in php.ini doesn't solve the problem.  WindRiver
> keeps its timezone files in /usr/share/zoneinfo
> (e.g. /usr/share/zoneinfo/GMT).  There is also a localtime time zone
> file in /etc.
> 
> I don't know if this is a php bug, or perhaps pilot-error on my part on
> either WindRiver Linux configuration or cross-compiling PHP. 
> 
> Thanks,
> Al

---

## #22499 — Derick Rethans — 2006-03-17T08:01:31+00:00

URL: https://externals.io/message/22497#22499 · In reply to: #22498

> Ok, I'm not sure what /etc/localtime was but when I copied
> over /usr/share/zoneinfo/America/New_York to /etc/localtime the problem
> went away and things are working gloriously-well.

Now that doesn't make a single bit of sense as the new date support in 
PHP 5.1 just tries to *avoid* all OS related things. Copying over those 
file is absolutely not going to have any effect. The 
timelib_parse_tzfile() function only operates on the built-in library.

Please provide a short reproducing script that shows this segfault. if 
you find one put it in a bugreport at http://bugs.php.net.

Derick

> 
> > […]
> 
> 

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
