Error: PHP Illegal offset type in isset or empty

[mmattel]

ubuntu 14.04, mysql, php 5.5.9, owncloud 8.0 pre alpha (git), external storage, no encryption, installed via ocdev base

I updated my dev environment today with a git pull (also on each app) which I last did about 2 weeks ago.
Owncloud responded with a maintenance upgrade. After taking a look into the owncloud logs I have found following, where the php error message is present in tons of.

Error PHP
Illegal offset type in isset or empty at /xxx/lib/private/app.php#138

Debug
core starting upgrade from 7.8.1.0 to 7.8.1.0

Fatal
index   Exception: {"Message":"","Code":0,"Trace":"#0 \/xxx\/lib\/private\/app.php(75): OC_App::loadApp('files_external')\n#1 \/xxx\/lib\/private\/util.php(73): OC_App::loadApps(Array)\n#2 \/xxx\/lib\/base.php(729): OC_Util::setupFS()\n#3 \/xxx\/index.php(28): OC::handleRequest()\n#4 {main}","File":"\/xxx\/lib\/private\/app.php","Line":93}

When I leave the admin page and goto files, back to admin, new "error php" messages like above are generated.

[MorrisJobke]

I experienced the same. I debuged a bit. It's because in this function at some time not a string is passed in but an object (type: OCA\Contacts\App) which then result in the above error. I don't know how this should be fixed

• return null if this happens (be tolerant to this case)
• find the cause of this and fix it there (because it's documented that a string needs to be passed in)

cc @icewind1991 @PVince81 - I think you had experience with the app loading stuff and it seems to be something like that.

[mmattel]

Hint:

Changing from the admin page directly to files (do nothing) and going back to the admin page creates about 69 (!) Error PHP log entries.

Somewhere in between, spreaded around without visible pattern are 3 messages:
Debug core OC_Image::loadFromFileHandle(): Trying

[PVince81]

Looks oddly similar to #11584
The linked issue has a similar error in the log.

@mmattel can you run the following SQL query:
select * from oc_appconfig where appid='files'

The first error in the log seems to imply that for some reason the files app has no "type" field.

[mmattel]

Via phpmyadmin

One question: why is the error php message 69 times present by only clicking once on the files app...

[PVince81]

@kedanli reported seeing this on OC 7.0.3 RC 1 on Windows Server.

If the "types" value is correct in the database, then maybe there's some kind of race condition that tries to read the "types" value from the internal cache but doesn't succeed.

Needs further research. I suspect app loading order issue.

[PVince81]

@MorrisJobke any clue how to reproduce this ? It doesn't happen on my env.

[PVince81]

@karlitschek @MTRichards @craigpg potential showstopper.

This error was already reported 4 times. Does not happen in all environments.

[MorrisJobke]

As mentioned. The only question is how should I fix that. I also have this. I can supply a workaround fix, but I'm not comfortable with this. I will prepare a PR and you can decide, what to do.

[PVince81]

Ok thanks. Because without being able to understand the root cause I can't fix this.
Your PR will help a bit. Thanks.

[PVince81]

Also the question is why this happens in the first place, and why it doesn't happen on all envs...

[MorrisJobke]

@PVince81 Can you enable the contacts app? This is the instance which is handed in instead of a string.

[PVince81]

Hmmm...... I enabled the contacts app and see it happening now.
But it doesn't break OC like @kedanli reported in the linked ticket.
Then maybe @kedanli is having additional unrelated issues.

Let's see what happens after the fix.

[PVince81]

I found the root cause: when loading an app with loadApp(), a local variable $app is defined.
But then when calling require_once for the contacts app, the contacts app also defines a $app variable which will OVERWRITE the local function's $app one. Nasty...

I'll try and move the require_once to its own function to avoid such scoping issues.

[MorrisJobke]

The fix will be released with 7.0.3

[mmattel]

@PVince81
Thanks for fixing this.
One question remains to me: why have I gotten this message so often logged by only clicking once to the files app? For me this means that the routine got called that many times and doesn´t that highlight a hidden performance impact?

[PVince81]

I think it's because multiple apps are being loaded, not only one.

[PVince81]

Also note that every ajax call from the JS side (to non-static resources) needs to re-init the whole PHP state, so app code needs to be reloaded for every ajax call.