[PHP-BUG] Bug #53587 [NEW]: Seek error: Invalid argument when creating ZIP larger than 2GB on 32bit arch
From:
Operating system: Linux, Mac OS X
PHP version: 5.3.4
Package: *Compression related
Bug Type: Bug
Bug description:Seek error: Invalid argument when creating ZIP larger than
2GB on 32bit arch
Description:
On 32bit system, you can't generate ZIP files larger than 2GB.
I reproduce this with :
- PHP 5.3.4 on Mac OS 10.5 i686
Also observed with :
- PHP 5.2.4 on Ubuntu 8.04 i686
- PHP 5.3.2 on Ubuntu 10.04 i686
I tested with 3 files of 1GB random data. After adding the 3 files, the
$zip-
close() returns the error Seek error: Invalid argument and there is no
zip
output file.
After looking into ext/zip, it seems that the problem is in the use of
unsigned
long types instead of the off_t type in zip_cdir struct, and the fact
that
the HAVE_FSEEKO and HAVE_FTELLO are not detected/defined by the ./configure
script.
On OS X (PHP 5.3.4), if I recompile the ext/zip extension by hand with the
patch
below (force HAVE_FSEEKO/HAVE_FTELLO and adjust the unsigned long to
off_t
in zip_cdir struct), then I can create my ZIP archive larger than 2GB.
Test script:
---
#!/bin/bash
# -- Create 3 files of 1GB random data
for I in 1 2 3; do dd if=/dev/urandom of=f$I bs=1M count=1024; done
# -- Create a 'out.zip' archive containing these 3 files
php -r '$zip = new ZipArchive(); $zip-open(out.zip, ZIPARCHIVE::CREATE);
$zip-addFile(f1); $zip-addFile(f2); $zip-addFile(f3); $ret =
$zip-close(); if( $ret === false ) { print sprintf(Error: %s,
$zip-getStatusString()); };'
zip -T out.zip
if [ $? -ne 0 ]; then
echo ERROR
exit 1
fi
echo OK
exit 0
Expected result:
A ZIP archive with a size around 3GB that passes the `zip -T' verification.
Actual result:
--
$zip-close() returns false with error Seek error: Invalid argument, and
the ZIP
output file is not produced.
--
Edit bug report at http://bugs.php.net/bug.php?id=53587edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53587r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53587r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53587r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53587r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53587r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53587r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53587r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53587r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53587r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53587r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53587r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53587r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53587r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53587r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53587r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53587r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53587r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53587r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53587r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53587r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53587r=mysqlcfg
Bug #53587 [Opn]: Seek error: Invalid argument when creating ZIP larger than 2GB on 32bit arch
Edit report at http://bugs.php.net/bug.php?id=53587edit=1
ID: 53587
User updated by:jerome dot auge at anakeen dot com
Reported by:jerome dot auge at anakeen dot com
Summary:Seek error: Invalid argument when creating ZIP
larger than 2GB on 32bit arch
Status: Open
Type: Bug
-Package:*Compression related
+Package:Zip Related
Operating System: Linux, Mac OS X
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Package: Zip Related
Previous Comments:
[2010-12-21 11:23:30] jerome dot auge at anakeen dot com
Description:
On 32bit system, you can't generate ZIP files larger than 2GB.
I reproduce this with :
- PHP 5.3.4 on Mac OS 10.5 i686
Also observed with :
- PHP 5.2.4 on Ubuntu 8.04 i686
- PHP 5.3.2 on Ubuntu 10.04 i686
I tested with 3 files of 1GB random data. After adding the 3 files, the
$zip-
close() returns the error Seek error: Invalid argument and there is
no zip
output file.
After looking into ext/zip, it seems that the problem is in the use of
unsigned
long types instead of the off_t type in zip_cdir struct, and the fact
that
the HAVE_FSEEKO and HAVE_FTELLO are not detected/defined by the
./configure
script.
On OS X (PHP 5.3.4), if I recompile the ext/zip extension by hand with
the patch
below (force HAVE_FSEEKO/HAVE_FTELLO and adjust the unsigned long to
off_t
in zip_cdir struct), then I can create my ZIP archive larger than 2GB.
Test script:
---
#!/bin/bash
# -- Create 3 files of 1GB random data
for I in 1 2 3; do dd if=/dev/urandom of=f$I bs=1M count=1024; done
# -- Create a 'out.zip' archive containing these 3 files
php -r '$zip = new ZipArchive(); $zip-open(out.zip,
ZIPARCHIVE::CREATE); $zip-addFile(f1); $zip-addFile(f2);
$zip-addFile(f3); $ret = $zip-close(); if( $ret === false ) { print
sprintf(Error: %s, $zip-getStatusString()); };'
zip -T out.zip
if [ $? -ne 0 ]; then
echo ERROR
exit 1
fi
echo OK
exit 0
Expected result:
A ZIP archive with a size around 3GB that passes the `zip -T'
verification.
Actual result:
--
$zip-close() returns false with error Seek error: Invalid argument,
and the ZIP
output file is not produced.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53587edit=1
[PHP-BUG] Bug #51282 [NEW]: crypt() result different between PHP 5.3.1 and PHP 5.3.2
From: Operating system: Mac, Linux PHP version: 5.3.2 Package: *Encryption and hash functions Bug Type: Bug Bug description:crypt() result different between PHP 5.3.1 and PHP 5.3.2 Description: I use crypt() to store and validate passwords using the « Standard DES » hash, and after upgrading to 5.3.2, the hashed password of an account is not the same as the one generated with PHP 5.3.1 : With PHP 5.3.1 : $ php -r 'print crypt(anakeen, A^).\n;' A^1ul2Jf7VS2M After upgrading to PHP 5.3.2 : $ php -r 'print crypt(anakeen, A^).\n;' A^/ImZ5hqd2VU I tested both on Mac (macports) and on Linux (rawhide), and the hash result was different on both platform. On Mac OS X (10.5), the Perl (or C) crypt gives me the same results as PHP 5.3.1 : $ perl -e 'print crypt(anakeen, A^).\n;' A^1ul2Jf7VS2M While on Linux, the Perl script gives me the same result as PHP 5.3.2. It appears that there is a difference in the crypt() function, between these platforms, regarding the presence of non alpha-num chars in the salt : Mac OS X with A- salt = different hashes : $ php -r 'print crypt(anakeen, A-).\n;' A-75An91LCLEM $ perl -e 'print crypt(anakeen, A-).\n'; A-1ul2Jf7VS2M Mac OS X with A9 salt = same hashes : $ perl -e 'print crypt(anakeen, A9).\n'; A9Pf3.gAayQMM $ php -r 'print crypt(anakeen, A9).\n;' A9Pf3.gAayQMM Maybe I should not have used non alpha-num chars for my salt in the first place ? -- Edit bug report at http://bugs.php.net/bug.php?id=51282edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51282r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51282r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51282r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51282r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51282r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51282r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51282r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51282r=needscript Try newer version: http://bugs.php.net/fix.php?id=51282r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51282r=support Expected behavior: http://bugs.php.net/fix.php?id=51282r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51282r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51282r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51282r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51282r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51282r=dst IIS Stability: http://bugs.php.net/fix.php?id=51282r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51282r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51282r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51282r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51282r=mysqlcfg
#45380 [NEW]: Access multiple sessions in a request
From: jerome dot auge at anakeen dot com
Operating system: Linux
PHP version: 5.2.6
PHP Bug Type: Session related
Bug description: Access multiple sessions in a request
Description:
I want to access two distinct sessions content, but I only get access to
the first session, and the second session_name/session_start does not
change the content of the $_SESSION variable which remains the same as
the first one.
After investigation, when switching session with a call to
session_name('another_session')+session_start(), the session ID from the
first session_start() is re-used, and the sess ID from the new session
name 'another_session' is not used.
Reproduce code:
---
1) Call 'set_sess1.php' to set a session named 'sess1':
?php
session_name('sess1');
session_start();
$session_id = session_id();
$cookie = $_COOKIE['sess1'];
$_SESSION['sess1']='session1:'.$session_id;
print cookie = .$cookie.\n;
print session_id = .$session_id.\n;
print _SESSION = .$_SESSION['sess1'].\n;
session_write_close();
?
2) Call 'set_sess2.php' to set a session named 'sess2':
?php
session_name('sess2');
session_start();
$session_id = session_id();
$cookie = $_COOKIE['sess2'];
$_SESSION['sess2']='session2:'.$session_id;
print cookie = .$cookie.\n;
print session_id = .$session_id.\n;
print _SESSION = .$_SESSION['sess2'].\n;
session_write_close();
?
3) Try to access both session variables in 'get_sess.php':
?php
session_name('sess1');
session_start();
$sess1 = $_SESSION['sess1'];
session_write_close();
session_name('sess2');
session_start();
$sess2 = $_SESSION['sess2'];
session_write_close();
foreach ($_COOKIE as $k = $v) {
print _COOKIE[$k] = $v\n;
}
print sess1 = $sess1\n;
print sess2 = $sess2\n;
?
Expected result:
In 'get_sess.php', I expect to get access to the content of the 'sess2'
session by issuing a new session_name('sess2')+session_start(), but the
content of _SESSION remains the one from 'sess1'.
Expected output from 'get_sess.php':
_COOKIE[sess1] = n0f57lap2oabeqvfc6t6c0ap60
_COOKIE[sess2] = b4s2sr976f4qrbkimfh0i6kqm0
sess1 = session1:n0f57lap2oabeqvfc6t6c0ap60
sess2 = session2:b4s2sr976f4qrbkimfh0i6kqm0
Actual result:
--
Actuel output from 'get_sess.php':
_COOKIE[sess1] = 2ot2t22ccq0t9de2edhgcrh4h4
_COOKIE[sess2] = rt8jr3e6esvmp88id0e4o05091
sess1 = session1:2ot2t22ccq0t9de2edhgcrh4h4
sess2 =
The script also issue a Set-Cookie: sess2=value_from_sess1, and I
end up with the cookies 'sess1' and 'sess2' having the same ID.
I got around it by setting the session ID manually with
session_id($_COOKIE['new_session']), after calling
session_name('new_session') and before session_start()... but I was
expecting PHP to handle this automatically...
So here is a proposal patch to de-allocate PS(id) when calling
session_write_close(), in order to force session_start() to lookup the
session ID from the session name:
--8--
--- php-5.2.6.orig/ext/session/session.c2008-04-29
16:42:38.0 +0200
+++ php-5.2.6/ext/session/session.c 2008-06-27 18:29:05.0
+0200
@@ -933,6 +933,11 @@
if (PS(mod_data))
PS(mod)-s_close(PS(mod_data) TSRMLS_CC);
+
+ if (PS(id)) {
+ efree(PS(id));
+ PS(id) = NULL;
+ }
}
static char *month_names[] = {
--8--
--
Edit bug report at http://bugs.php.net/?id=45380edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45380r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45380r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45380r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45380r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45380r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45380r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45380r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45380r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45380r=support
Expected behavior:http://bugs.php.net/fix.php?id=45380r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45380r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45380r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45380r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45380r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45380r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45380r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45380r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45380r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45380r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45380r
