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

But why would articles have the same submission file id? I can’t think of a reason why that would happen.

In any case I’ve removed all articles with tools/deleteSubmissions.php that have that particular file id, let’s see if it works. The waiting is what kills me :slight_smile: . I’ve cleared the metrics table but that did not reduced the time it takes to upgrade, I’m still around 8 hours.

It is weird that it takes 8 hours even without the metrics. Or you have a large database to begin with with a lot of journals and submissions. If that is the case, prepare for a very very long upgrade with the metrics table and when you get past these errors. I did an upgrade with a database with 100 journals and it took 36 hours to complete and 30 hours of that was upgrading the metrics table. But it probably does not affect your upgrade yet, because you probably crash before that.

With the nulls, it could be that you need to have this commit: pkp/pkp#3783 consider supp files without file id in the migration · pkp/ojs@1899a4e · GitHub (which you have, if you use the latest stable branch for 3.1.1 from Github, but if you downloaded OJS from the PKP site, you do not have that).

There are a lot of cases where you have a single file_id with several revisions. If for example in OJS2 a reviewer uploaded several review files, all those files have the same file_id and just a different revision number. I do not remember all the places where OJS2 created revisions of the same file, but there are definitely other places as well.

But if I understand correctly the duplicates have to come originally from here: ojs/Upgrade.inc.php at ojs-stable-3_1_1 · pkp/ojs · GitHub so check the original article_supplementary_files table for duplicate entries.

It does not seem to have reduced any significantly when I truncated the metrics table.
Database dump takes 106mb, so I would say very small, and maybe around 25GB of files.

I do have that patch though, I’ve applied manually as a tentative to fix the issue.

For this duplicate, it is always the same revision (1). I will check the supplementary_files table once I’m at home to take a look.

Edit:
I see it spends quite a long time on (4 hours already):

UPDATE articles SET review_file_id=NULL WHERE review_file_id = 0

-----<hr>
-----<hr>
(mysql): DELETE FROM review_rounds WHERE submission_id = 24372

-----<hr>
-----<hr>
(mysql): SELECT file_id, revision, file_name FROM article_files WHERE file_id = 0

-----<hr>
-----<hr>
(mysql): DELETE FROM article_files WHERE file_id = 0

-----<hr>
-----<hr>
(mysql): UPDATE articles SET review_file_id=NULL WHERE review_file_id = 0

-----<hr>

hmm, maybe there are not that much statistics gathered then. I our installation the metrics table takes up half of the database size, 600 megabytes out if 1GB and in a similar installation with 100 journals it takes, as I mentioned above, around 30 hours to complete a single sql (out of the 36 hours total it took to upgrade). But you are probably not even reaching the part where the metrics table updates start.

The part you mentioned does take a considerable amount of time as well, true.

This looks like the next part which takes most time:

(mysql): UPDATE submission_files SET file_stage=10 WHERE file_id IN (SELECT file_id FROM submission_galleys)

+----+------+-----------------------------------+----------+---------+------+--------------+-----------------------------------------------------------------------------------------------------+
| Id | User | Host                              | db       | Command | Time | State        | Info                                                                                                |
+----+------+-----------------------------------+----------+---------+------+--------------+-----------------------------------------------------------------------------------------------------+
| 24 | root | localhost                         | revistas | Query   | 5015| Sending data | UPDATE submission_files SET file_stage=10 WHERE file_id IN (SELECT file_id FROM submission_galleys) |
| 64 | root | localhost                         | NULL     | Query   |    0 | NULL         | show processlist                                                                                    |
+----+------+-----------------------------------+----------+---------+------+--------------+-----------------------------------------------------------------------------------------------------+

Ok, now this borders the ridiculous.
I’m still getting the same error with duplicate 2147483647, but i have zero mentions of that id in the whole database before the upgrade. How is that possible?

I was going to say earlier that the number sounds weird (big). Seems that there is something special about that number php - Incorrect Integer (2147483647) is inserted into MySQL? - Stack Overflow. It is basically the biggest number there is in mysql.

So I think that, for some reason, the upgrade keeps looping something almost indefinitely, something it should not, and ends up trying to insert that max number twice => your error.

I think that in order get into bottom of this, you need to add some debugging code around here: ojs/Upgrade.inc.php at ojs-stable-3_1_1 · pkp/ojs · GitHub

Maybe @asmecher has some pointers to this, this is nothing I have seen before.

edit: or do you have values larger than that number as a file_id in the article_supplementary_files table? Because in a 32 bit system that is the highest value being supported I think and any higher value than that would be converted to 2147483647.

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: