While trying to run my testcases from: https://bugs.mageia.org/show_bug.cgi?id=3895#c35 I noticed that the ones using php-dba and php-gd won't work. I even made smaller testcases that only use one or the other, and those don't work either. No errors are reported in /var/log/httpd/error.log. Things work fine in Mageia 1, and there are no functional differences in the PHP package between Mageia 1 and Cauldron, so I don't think the bug is in the php package itself, but I have no idea what's causing this problem or how to even start debugging it.
Priority: Normal => release_blockerCC: (none) => thomas
OK, there was a bug in one of my separated testcases, php-gd works. php-dba does not work.
Summary: PHP modules don't work => PHP php-dba module doesn't work
Running through strace on Mageia 1 and Mageia 2, right after it opens the database file, it calls read(). Then, on Mageia 1 it calls lseek(): lseek(3, 4096, SEEK_SET) = 4096 However, on Mageia 2 it calls _llseek(): _llseek(3, 17592186048512, 0xbff2d360, SEEK_SET) = -1 EINVAL (Invalid argument) Afterward, on Mageia 1 in continues to read and write the database file before closing it. On Mageia 2, it immediately closes the file after that error.
Looking at the _llseek man page, it looks like there is an argument missing in the middle of the call. It should be (fd, offset_high, offset_low, *result, whence), so the fd, one of the offsets, the address for the result, and the whence are there.
Note that I'm using a gdbm database file, so the problem is probably in libgdbm.
libgdbm only calls lseek() and __lseek(), so is the problem in glibc?
CC: (none) => tmb
You can test it by just running php test.php on the command line, with this test.php (php-cli and php-dba installed): <HTML> <BODY> <?php $counters = dba_open("counters.db","c","gdbm"); $page = "test.php"; $count = dba_fetch($page, $counters); $count+=1; dba_replace($page, $count, $counters); $count = dba_fetch($page, $counters); dba_sync($counters); dba_close($counters); print "The count is: "; print $count; ?> </BODY> </HTML>
If I delete counters.db and start over, it actually works. Using the existing one I have (see attachment linked in Comment 0), it doesn't.
Also, trying to run a similar program as a PHP CGI with php-cgi and apache-mod_suexec isn't working, because the suexec isn't actually executing it, so it doesn't have write access to counters.db. I know mod_suexec worked right after I merged it into the apache SRPM, because I tested it then.
Bug 5764 filed for the suexec issue.
Summary: PHP php-dba module doesn't work => PHP php-dba module doesn't work with existing gdbm database file
does a simple rebuild of the srpm change anything ?
(In reply to comment #10) > does a simple rebuild of the srpm change anything ? Of which SRPM? Certainly not of the PHP one, as I tried it with the current (as of yesterday) packages in Cauldron as well as a local build of the 5.3.11 update I was trying to get pushed, and I had the problem with both.
the gdbm one. (if it needs to pick up glibc/kernel header changes)
(In reply to comment #12) > the gdbm one. (if it needs to pick up glibc/kernel header changes) OK, I tried rebuilding gdbm. That didn't fix it either.
This can be fixed after release through updates. Decreasing priority
Priority: release_blocker => HighCC: (none) => ennael1
Source RPM: php-5.3.10-8.mga2.src.rpm => gdbm-1.10-1.mga2.src.rpm
CC: (none) => mageia
CC: (none) => fundawang
I tried downgrading to gdbm 1.9.1 (still library major version 4), and that had the same problem. Then I rebuilt php against libgdbm3 from Mageia 1, and it works. It looks the gdbm database format changed. What else might this break?
OK, I converted my PHP program to a C program that only uses gdbm. If you build it on Mageia 1 (or against libgdbm3) and run it, then build it on Mageia 2 against libgdbm4 and run it again with the testdb.db created from the first run, you see the same __llseek in strace, and then it segfaults. If you delete the testdb.db and let it make a fresh one, it works. #include <gdbm.h> #include <stdlib.h> #include <stdio.h> #include <string.h> int main() { GDBM_FILE dbf; int ret, nextval; datum key, value; dbf = gdbm_open("testdb.db", 1024, GDBM_WRCREAT, 0644, NULL); key.dptr = "foo"; key.dsize = strlen(key.dptr); value = gdbm_fetch(dbf, key); if (value.dptr == NULL) { value.dptr = "0"; value.dsize = strlen(value.dptr); } sscanf(value.dptr, "%d", &nextval); nextval++; value.dptr = malloc((value.dsize+1)*sizeof(char)); sprintf(value.dptr, "%d", nextval); value.dsize = strlen(value.dptr); ret = gdbm_store(dbf, key, value, GDBM_REPLACE); value = gdbm_fetch(dbf, key); sscanf(value.dptr, "%d", &nextval); gdbm_sync(dbf); gdbm_close(dbf); printf("The count is: %d\n", nextval); return(0); }
Summary: PHP php-dba module doesn't work with existing gdbm database file => gdbm doesn't work with existing gdbm database files created with previous library version
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
Nothing has changed with this one. I'll change this one to Mageia 2.
Keywords: NEEDINFO => (none)Version: Cauldron => 2
Keywords: (none) => Triaged
This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad
Version: 2 => Cauldron
This bug is becoming very old (but it can still be valid, I don't know). What do you think, David?
Yeah it's unfortunate. It's certainly valid, but anyone that was bitten by it would have had to deal with it by now. Upstream really screwed up. Hopefully it won't happen again. I'll close this as WONTFIX.
Status: NEW => RESOLVEDResolution: (none) => WONTFIX