Upgrade to 3.1.1-2 from 2.4.8 PHP Fatal error: Call to a member function getStatus()

You see, now that’s an amazing rationale and it makes sense to me, including my is it taking so long.
I’m trying to upgrade using the 3.0.2 now to see what happens (although I tried before but was before handling the null issues). I will investigate this after it finishes (or crashes)

3.0.2 failed with the below error:

(mysql): SELECT * FROM users WHERE user_id = 23

-----<hr>
-----<hr>
(mysql): SELECT * FROM user_settings WHERE user_id = '23'

-----<hr>
PHP Warning:  assert(): Assertion failed in.../lib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 355
PHP Fatal error:  Call to a member function getFilePath() on null in .../lib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 377

@ajnyga On article_supplementary_files there are 30 entries, nothing bigger than 46371, so it looks legit. Now we need to find what could be causing the loop.

and nothing larger than that number for the file_id value in article_supplementary_files? Or anything special in any values in that field?

if you have a database dump done after the crash, you could try what happens with sql here ojs/Upgrade.inc.php at ojs-stable-3_1_1 · pkp/ojs · GitHub

You probably can not test that against an existing OJS2 db.

For the upgrade I would add a debug code
here: ojs/Upgrade.inc.php at ojs-stable-3_1_1 · pkp/ojs · GitHub

error_log(“article_id”);
error_log(print_r($suppFilesRow[‘article_id’], true));
error_log(“file_id”);
error_log(print_r($suppFilesRow[‘file_id’], true));
error_log(“latest_revision”);
error_log(print_r($revisionNumber, true));

and before this line: ojs/Upgrade.inc.php at ojs-stable-3_1_1 · pkp/ojs · GitHub

error_log(“newFileId”);
error_log(print_r($newFileId, true));
error_log(“newRevision”);
error_log(print_r($newRevision, true));

This of course will add a lot of rows to the error_log, but should indicate what values you have right before the crash.

Nothing larger than that.

But I think I made some breakthrough: When you mentioned the 32bit limit, I started to think if this could be somehow related to the container where this is running. All the upgrades until the 2.4.8 were fine, so I did not though much about it. But I’m using openvz for containers (in one a bit old installation of proxmox). I cannot upgrade proxmox to get newer container templates as I’m physically away from the server and I don’t want to risk something happening. But I am able to run a full VM in there with KVM, so that’s what I did: I’m now running the upgrade process in a VM instead of a container and it looks like it passed that error - but it stopped in the middle because of other issues (the file storage is in a NAS that got disconnected) so I need to start again to see if it goes all the way to the end.

I’m starting to think that the container may be misbehaving somehow: we will see. I will report back tomorrow.

2 Likes

Good news is that it is confirmed: The container was somemehow misbehaving with the sql server.

Bad news is that the upgrade still failed

-----<hr>
PHP Warning:  get_class() expects parameter 1 to be object, null given in /var/www/ojslib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 352
PHP Fatal error:  Uncaught Error: Call to a member function getFilePath() on null in /var/www/ojslib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php:371
Stack trace:
#0 /var/www/ojsclasses/install/Upgrade.inc.php(1043): PKPSubmissionFileDAO->updateObject(Object(SubmissionFile))
#1 /var/www/ojslib/pkp/classes/install/Installer.inc.php(421): Upgrade->setFileName(Object(Upgrade), Array)
#2 /var/www/ojslib/pkp/classes/install/Installer.inc.php(265): Installer->executeAction(Array)
#3 /var/www/ojslib/pkp/classes/install/Installer.inc.php(186): Installer->executeInstaller()
#4 /var/www/ojslib/pkp/classes/cliTool/UpgradeTool.inc.php(88): Installer->execute()
#5 /var/www/ojslib/pkp/classes/cliTool/UpgradeTool.inc.php(64): UpgradeTool->upgrade()
#6 /var/www/ojstools/upgrade.php(34): UpgradeTool->execute()
#7 {main}
  thrown in /var/www/ojslib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 371

Maybe this helps: Upgrade OJS 2.4.8 to OJS 3

1 Like

Thanks but not the case :frowning: My files are located in the right place and are accessible by the script. I’ve done a chmod 777 -R just to make sure (for testing purposes).

In all cases,
I’m again restoring an original backup of the files, since I got past the 2147483647 error to try again.

@ajnyga Yep. Even 777ed, with original files and all, I still get

PHP Warning:  get_class() expects parameter 1 to be object, null given in /var/www/ojs/lib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 352
PHP Fatal error:  Uncaught Error: Call to a member function getFilePath() on null in /var/www/ojs/lib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php:371
Stack trace:
#0 /var/www/ojs/classes/install/Upgrade.inc.php(1043): PKPSubmissionFileDAO->updateObject(Object(SubmissionFile))
#1 /var/www/ojs/lib/pkp/classes/install/Installer.inc.php(421): Upgrade->setFileName(Object(Upgrade), Array)
#2 /var/www/ojs/lib/pkp/classes/install/Installer.inc.php(265): Installer->executeAction(Array)
#3 /var/www/ojs/lib/pkp/classes/install/Installer.inc.php(186): Installer->executeInstaller()
#4 /var/www/ojs/lib/pkp/classes/cliTool/UpgradeTool.inc.php(88): Installer->execute()
#5 /var/www/ojs/lib/pkp/classes/cliTool/UpgradeTool.inc.php(64): UpgradeTool->upgrade()
#6 /var/www/ojs/tools/upgrade.php(34): UpgradeTool->execute()
#7 {main}
  thrown in /var/www/ojs/lib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 371

@ajnyga Do you have anything else I could try? I’ve kinda given up on this and I think I will have to just leave a read only copy of the first and start a new one with 3.1. I have no idea what to do anymore. I’ve tried adding some debug at the point it breaks but I got nothing (literally nulls :slight_smile:) .
In any case, thanks for the help thus far.

Do you remember what stage of the upgrade that is happening in? I mean what is the script that upgrade is running when that happens? Which of these: ojs/upgrade.xml at ojs-stable-3_1_1 · pkp/ojs · GitHub

@ajnyga This is the last stage that I saw.

[code: Installer Installer::setFileName]

I tried to add a debug function to see if the issues was with the path, but as the error message states, the path is null because the whole variable $previousFile is null.

$previousFilePath = $previousFile->getFilePath();

I’ve decided to upgrade everything in the virtualizer and start again from scratch to see what happens: But I’m felling I will hit the same errors. Would appreciate any other possible insights you may have .

Did you try to check the file_id that is being fetched here: pkp-lib/PKPSubmissionFileDAO.inc.php at ojs-stable-3_1_1 · pkp/pkp-lib · GitHub

I mean the values for $previousFileId and $previousRevision

Could be a good idea to add some code there that would print out those values and see what you find with that file id from the database.


updateObject is called here: ojs/Upgrade.inc.php at ojs-stable-3_1_1 · pkp/ojs · GitHub

You could also check from line 1031 what submission id you have just before it crashes.

No in those variables. Let’s see if I can add some debug code there. I suck at PHP so I would appreciate any pointers. Also, It’s super terrible to add some code and then wait 8h just to see it failing because I’ve added it incorrectly :frowning:

lines like error_log(print_r($newRevision, true)); should work. Just replace the variable with the actual name.

I would add error_log(print_r($updatedFile->getFileId(), true)); before this line pkp-lib/PKPSubmissionFileDAO.inc.php at ojs-stable-3_1_1 · pkp/pkp-lib · GitHub to find out the fileId where the problem is.

But also here ojs/Upgrade.inc.php at ojs-stable-3_1_1 · pkp/ojs · GitHub I would add error_log("SubmissionId"); error_log(print_r($submission->getId(), true)); Because if the $updatedFile->getFileId() returns another null, you can at least check what the submission id is where the problem occurs and start tracking it there.

Thank you. I’m starting a new round of upgrade with the relevant debug code and also using 3.1.1-4 which as been just released. Will report back in the morning.

@ajnyga

Ok, this is what I got:

(mysql): SELECT * FROM user_settings WHERE user_id = '23'

-----<hr>
31350
31350
0
PHP Warning:  assert(): Assertion failed in /var/www/ojs/lib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 352
PHP Fatal error:  Call to a member function getFilePath() on null in /var/www/ojs/lib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 374
-----<hr>

Since I have added the below debug:

  // Make sure that the implementation of the updated file                                                                      │·······························································································································
                // is compatible with its genre.                                                                                              │·······························································································································
                error_log(print_r($updatedFile->getFileId(), true));                                                                          │·······························································································································
                $updatedFile = $this->_castToGenre($updatedFile);                                                                             │·······························································································································
                                                                                                                                              │·······························································································································
                // Complete the identifying data of the previous file if not given.                                                           │·······························································································································
                $previousFileId = (int)($previousFileId ? $previousFileId : $updatedFile->getFileId());                                       │·······························································································································
                $previousRevision = (int)($previousRevision ? $previousRevision : $updatedFile->getRevision());                               │·······························································································································
                                                                                                                                              │·······························································································································
                // Retrieve the previous file.                                                                                                │·······························································································································
                error_log(print_r($previousFileId, true));                                                                                    │·······························································································································
                error_log(print_r($previousRevision, true));                                                                                  │·······························································································································
                $previousFile = $this->getRevision($previousFileId, $previousRevision);                                                       │·······························································································································
                assert(is_a($previousFile, 'SubmissionFile'));                        

The codes should the getFileID and somehow the previousFileID and the previousRevision
31350
31350
0

In this case:

mysql> select * from article_files where file_id = 31350;
+---------+----------+----------------+-----------------+------------+------------------------+-----------------+-----------+------------------------+------------+----------+---------------------+---------------------+-------+----------+
| file_id | revision | source_file_id | source_revision | article_id | file_name              | file_type       | file_size | original_file_name     | file_stage | viewable | date_uploaded       | date_modified       | round | assoc_id |
+---------+----------+----------------+-----------------+------------+------------------------+-----------------+-----------+------------------------+------------+----------+---------------------+---------------------+-------+----------+
|   31350 |        0 |           NULL |            NULL |      31350 | 31350-35163-10-PB.html | application/pdf |    324352 | 31350-35163-10-PB.html |          7 |     NULL | 2010-03-06 04:28:12 | 2010-03-06 04:28:12 |     1 |     NULL |
|   31350 |        1 |          31349 |            NULL |      30338 | 30338-31350-1-RV.pdf   | application/pdf |     18501 | 30338-31349-1-SM.pdf   |          2 |     NULL | 2009-04-06 15:36:20 | 2009-04-06 15:36:20 |     1 |     NULL |
+---------+----------+----------------+-----------------+------------+------------------------+-----------------+-----------+------------------------+------------+----------+---------------------+---------------------+-------+----------+
2 rows in set (0.01 sec)

I’m not sure about those results, but is this because file_id is not unique? Also, file_id has same article_id on the first, but not on the second(also file name is weird)?

Also, here are all non unique file_id - Not sure if this is a problem

mysql> select file_id, COUNT(*) from article_files GROUP BY file_id HAVING count(*) > 1;
+---------+----------+
| file_id | COUNT(*) |
+---------+----------+
|   31350 |        2 |
|   31898 |        2 |
|   31904 |        2 |
|   32051 |        3 |
|   32572 |        2 |
|   32573 |        4 |
|   37000 |        2 |
|   37265 |        2 |
|   37457 |        2 |
|   37458 |        3 |
|   39933 |        2 |
|   42195 |        2 |
|   44576 |        2 |
|   44854 |        4 |
|   44867 |        3 |
|   44868 |        3 |
|   44871 |        3 |
|   44890 |        3 |
|   44895 |        3 |
|   44897 |        3 |
|   44899 |        3 |
|   44901 |        3 |
|   44909 |        3 |
|   44919 |        3 |
|   44929 |        2 |
|   44977 |        3 |
|   44978 |        2 |
|   44979 |        2 |
|   44980 |        2 |
|   44981 |        2 |
|   44982 |        2 |
|   44991 |        2 |
|   45075 |        4 |
|   45079 |        3 |
|   45087 |        3 |
|   45119 |        3 |
|   45131 |        2 |
|   45143 |        2 |
|   45145 |        2 |
|   45155 |        2 |
|   45163 |        2 |
|   45166 |        2 |
|   45169 |        2 |
|   45175 |        3 |
|   45179 |        3 |
|   45183 |        3 |
|   45194 |        2 |
|   45256 |        2 |
|   45258 |        2 |
|   45259 |        2 |
|   45263 |        2 |
|   45282 |        3 |
|   45294 |        2 |
|   45298 |        2 |
|   45301 |        2 |
|   45358 |        2 |
|   45359 |        2 |
|   45365 |        2 |
|   45388 |        2 |
|   45389 |        2 |
|   45403 |        2 |
|   45413 |        2 |
|   45415 |        2 |
|   45436 |        2 |
|   45578 |        3 |
|   45611 |        2 |
|   45624 |        2 |
|   45625 |        2 |
|   45645 |        2 |
|   45650 |        2 |
|   45677 |        3 |
|   45678 |        2 |
|   45685 |        2 |
|   45796 |        2 |
|   45801 |        2 |
|   45857 |        2 |
|   45867 |        2 |
|   45869 |        2 |
|   45871 |        2 |
|   45875 |        2 |
|   45913 |        2 |
|   45919 |        2 |
|   45955 |        2 |
|   45956 |        2 |
|   45959 |        2 |
|   45998 |        2 |
|   46000 |        2 |
|   46006 |        2 |
|   46016 |        3 |
|   46027 |        2 |
|   46028 |        3 |
|   46034 |        2 |
|   46138 |        2 |
|   46144 |        2 |
|   46155 |        2 |
|   46182 |        6 |
|   46199 |        2 |
|   46248 |        4 |
|   46252 |        2 |
|   46253 |        2 |
|   46335 |        2 |
+---------+----------+

And I have some pretty high numbers in the file_id column as well…

|  46437 |        1 |
|  313500000 |        1 |
|  341230000 |        1 |
|  342900000 |        1 |
| 3135031354 |        1 |
| 3135031358 |        1 |
| 3135031359 |        1 |
| 3135031360 |        1 |
| 3135031361 |        1 |
| 3135031362 |        1 |
| 3135031363 |        1 |
+------------+----------+

Last edit:
Also: see how 3150 is the smallest non-duplicated file_id ? This probably means something right? Too unusal that it would error out exactly on the smallest numeber (if it goes sequencially)

I do not think that any file should have revision 0? It should be at least 1. That is the source of the error I bet.

In the original database, do you have a lot of files with revision number 0?

The file_id also looks weird. Is that in the original database?

edit: the file_id number 31350 has problems and the weird file_id’s start with 31350. That can not be a coincidence?

edit2: 3135031363 has actually two file_id’s together for some reason. Maybe the cause of your long loop we discussed above. I looks like two file_id’s have been embedded together somehow…

ok so you do not actually have two file_id’s with 31350.

On row 1 31350 is actually the article/submission id. The real file_id there is 35163 as you can see from the original file_name

On row 2 the file_id is the actual file_id and the submission/article id is 30338.

Look at the original database. Search for submissions 31350 and 30338 and see what files are attached to those two submissions/articles. There has to be something weird there.

In the original database, what kind of revisions do you have for file_id 35163? Do you have a zero there? The one mentioned above should be revision 10 as you can see from the filename.

Yes, this is from the original database.

mysql> select file_id from article_files where revision = 0;
+---------+
| file_id |
+---------+
|   31350 |
+---------+
1 row in set (0.02 sec)

That’s the only one with revision 0:

Edit: here is for 35163

mysql> select * from article_files where file_id = 35163;
+---------+----------+----------------+-----------------+------------+----------------------+-----------------+-----------+-------------------------------------+------------+----------+---------------------+---------------------+-------+----------+
| file_id | revision | source_file_id | source_revision | article_id | file_name            | file_type       | file_size | original_file_name                  | file_stage | viewable | date_uploaded       | date_modified       | round | assoc_id |
+---------+----------+----------------+-----------------+------------+----------------------+-----------------+-----------+-------------------------------------+------------+----------+---------------------+---------------------+-------+----------+
|   35163 |        1 |           NULL |            NULL |      31350 | 31350-35163-1-PB.pdf | application/pdf |    143981 | Microsoft Word - artigo busques.pdf |          7 |     NULL | 2009-06-15 15:50:31 | 2009-06-15 15:50:31 |     1 |     NULL |
+---------+----------+----------------+-----------------+------------+----------------------+-----------------+-----------+-------------------------------------+------------+----------+---------------------+---------------------+-------+----------+
1 row in set (0.00 sec)

can you show the whole row with *