Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Update from: Drupal 6.17
Update to: Drupal 7 dev snapshot from June 14
Full message:
Notice: Undefined index: update_success in update_results_page() (line 162 of /opt/lampp/htdocs/drupal-dev/update.php).
Warning: reset(): Passed variable is not an array or object in update_results_page() (line 166 of /opt/lampp/htdocs/drupal-dev/update.php).
Warning: array_pop(): The argument should be an array in update_results_page() (line 166 of /opt/lampp/htdocs/drupal-dev/update.php).
Comment | File | Size | Author |
---|---|---|---|
error2.png | 98.71 KB | Jarek Foksa |
Comments
Comment #1
Jarek Foksa CreditAttribution: Jarek Foksa commentedComment #2
grendzy CreditAttribution: grendzy commentedCan you provide any additional details? I have not been able to reproduce this issue.
Comment #3
ctmattice1 CreditAttribution: ctmattice1 commentedI get this error all the time on a vista box with xampp.
I'm not sure the exact cause of the problem but it raises it's ugly head when the update fails. when I traced it down further it appears to be related to a similar issue dealing with an empty sessions variable or cookie but don't remember the outcome of that particular issue. It seems that someone got around the issue by using IE and claimed it was a bug in firefox. I use firefox predominately and haven't tried a update using IE or one of the other browsers.
Comment #4
Jarek Foksa CreditAttribution: Jarek Foksa commentedI'm also using XAMPP. I was able to finish update process by re-runnig update.php script again.
Comment #5
Pls CreditAttribution: Pls commentedSo it's fixed if it works. Changing status
Comment #6
ctmattice1 CreditAttribution: ctmattice1 commentedUmmm,
No it is not fixed. Not on my dev machine anyway.
Have gotten it twice today.
Comment #7
ctmattice1 CreditAttribution: ctmattice1 commentedBut taking off critical, should actually be major
Comment #8
webernet CreditAttribution: webernet commentedI'm seeing this issue as well.
Comment #9
blavish CreditAttribution: blavish commentedI'm still seeing this issue. Normal upgrade on godaddy hosting.
Comment #10
Damien Tournoud CreditAttribution: Damien Tournoud commentedMike so that yesterday when trying to update a full D6 database we have. Promoting to critical, I suspect that the session handler is killing the session for some reason, investigating how this could happen.
Comment #11
mrfelton CreditAttribution: mrfelton commentedDo we have/can we get some solid steps to reproduce this issue?
Comment #12
nw CreditAttribution: nw commentedI saw this today, with brian_c, when running a test update on Visit Calgary - http://www.visitcalgary.com
However, attempts to recreate have been unfruitful. Brian and I are investigating further and will report in due course.
Comment #13
brian_c CreditAttribution: brian_c commentedUnfortunately really nothing further to report, we saw this just ONCE (the very first time, as a matter of fact), and were unable to reproduce it again all day. Tried with and without clearing cookies/cache/etc first, no difference.
The one time it did happen was on nw's Macbook, using Firefox on a hand-rolled AMP stack. The site we used had cache cleared right before export, and was set to a theme that didn't exist in D7, if that has any bearing. We tried running update.php again when this happened, but update said there was nothing left to do, and we were able to run the site afterwards.
If this is an intermittent Firefox-only issue, that does not actually prevent upgrade from completing even when it does occur (has this actually made anyone's upgrade impossible?) maybe for now we can just address this by trapping the error (check for empty session in update_results_page()) and providing a friendlier message (which could suggest trying a non-Firefox browser if the problem persists), and perhaps also with a request to report it?
Hard to think of what else to suggest without a way to reproduce this reliably, and while not knowing the root cause is certainly worrisome and warrants continued investigation, it's not what I would consider a launch stopper? Not my call of course.
I'm also not sure the title of this issue is accurate, has anyone seen evidence that the process is actually aborted mid-way? Seems more like a browser-specific issue causing session to be unavailable when it hits the results page. But again, I've only seen it manifested once, so people who've seen it repeatedly please weigh in.
Comment #14
webchickYeah, this sounds a bit suspect. "Undefined index" is only an E_NOTICE level error, and shouldn't halt progression of any subsequent code. It looks ugly, but doesn't break anything (under normal circumstances).
I'm going to demote the priority of this issue and mark "needs more info" until someone can post back with information on how to reproduce.
Thanks for all your hard diagnostic work though. It's really great to rule things in or rule them out.
Comment #15
brian_c CreditAttribution: brian_c commentedTweaked title to be more accurate and slightly less alarming, while retaining same info
Comment #16
webernet CreditAttribution: webernet commentedRan an update on the latest HEAD from a DB dump from earlier today with update_free_access = true
Looking through the log after running the update, it appears the error appears after "Updating field type file with module file." -- "PDOException: SQLSTATE[23000]: Integrity constraint..." (I can't read the rest, admin/reports/event/### is blank...)
Comment #21
dwwI know it's confusing, but "update.module" is for the part of core (added in 6.x) that checks for available updates to your modules and themes (now called the "Update manager" since it can also install/update your code). Sounds like y'all are talking about update.php, which is the "update system" component...
Comment #22
ctmattice1 CreditAttribution: ctmattice1 commentedJust got this again today. Happens every time I do d6->d7 upgrade.
Steps I use.
start with a d6.19 database.
delete all prior d7 files on my dev machine, except sites.
use the same settings.php file I've previously used to do upgrades.
The sites/all/modules folder has no d6 modules in it, purposely stripped out but does have the latest cvs of coder and devel.
Since i'm NOT logged in $update_free_access has been set to true.
run the upgrade and get the infamous warning
* Notice: Undefined index: update_success in update_results_page() (line 162 of C:\sites\d6d7\update.php).
* Warning: reset(): Passed variable is not an array or object in update_results_page() (line 166 of C:\sites\d6d7\update.php).
* Warning: array_pop(): The argument should be an array in update_results_page() (line 166 of C:\sites\d6d7\update.php).
click the administration link it correctly goes to the site under maintenance page.
Log in
now set the timezone
and can access dblog.
log consists of:
Haven't been able to track down why I continually get this error. It's more annoying than anything. Other than the warning the site appears functional but would still like to know why this occurs. With the changes to what dblog now displays (HOORAY) I'm wondering if it has to do with the exception.
Unfortunately if I click the link all that comes up is the "site under maintenance" page so I can't track it further.
Comment #23
blavish CreditAttribution: blavish commentedI get the same error.
After upgrade imagefield imagefields and filefields are gone I dont know if it is related to this error.
Here is my error that I posted on the forum:
I got the following error when upgrading from 6 to 7:
* Notice: Undefined index: update_success in update_results_page() (line 162 of /home/site/public_html/7/update.php).
* Warning: reset(): Passed variable is not an array or object in update_results_page() (line 166 of /home/site/public_html/7/update.php).
* Warning: array_pop(): The argument should be an array in update_results_page() (line 166 of /home/site/public_html/7/update.php).
This happens with the latest dev version of 12 October 2010
Comment #24
tobiasbthe user 0 must have the uid 0 in the database. with uid > 0 e.g. 3, I get also these error messages.
Comment #25
Taxoman CreditAttribution: Taxoman commentedSubscribing.
Comment #26
webernet CreditAttribution: webernet commented#24 is correct. After copying the DB with PHPmyadmin, uid = 0 gets replaced with uid = Max+1.
With RC1, resetting the uid to 0 before running the upgrade fixes things...
Comment #27
carlos8f CreditAttribution: carlos8f commentedIf #24 and #26 are correct, this is the classic "uid=0 missing" bug.
- production db is copied using phpMyAdmin (or similar), resulting sandbox/upgrade database has lost its uid=0 row
- anonymous users can no longer carry session data.
SELECT u.*, s.* FROM {users} u INNER JOIN {sessions} s ON u.uid = s.uid WHERE s.sid = :sid
in session.inc fails to find session data because of the INNER JOIN with a missing user row.- upgrades performed as the anonymous user will fail
- mollom or other anonymous session-using modules fail
- etc.
This could all be avoided if you 1) manually create a uid=0 row after the copy, or 2) if Drupal just didn't depend on such INNER JOIN queries with a row that may not even be copied correctly. I'm marking this as a duplicate of #989852: Kill uid=0 requirement, an initiative for D8.
Comment #28
yan CreditAttribution: yan commentedI can confirm that this happens when uid of anonymous user isn't 0.
Comment #29
dwwStill duplicate with #989852: Kill uid=0 requirement, just repairing the component.
Comment #30
jenlamptonLooks like this is still a problem with the d6 -> d7 upgrade path (still happened to me on 7.18). Since this issue has been closed (?) I opened a new one here: #1870948: D6 -> D7 core upgrade path terminates prematurely when the users table does not have a row with uid 0