New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PHP Catchable fatal error: Argument 1 passed to SMW\Subobject::__construct() #1318

Closed
kghbln opened this Issue Dec 16, 2015 · 15 comments

Comments

Projects
None yet
3 participants
@kghbln
Member

kghbln commented Dec 16, 2015

  • MediaWiki: 1.25.3
  • Semantic MediaWiki: 2.3.0
  • PHP: 5.6.11
  • MySQL: 5.6.27

This is acutally from the new smw.o site on the new server:
php rebuildData.php -v -d 25 --report-runtime

Running for storage: SMWSQLStore3

Removing marked for deletion entries.
PHP Catchable fatal error:  Argument 1 passed to SMW\Subobject::__construct() must be an instance of Title, null given, called in /.../w/extensions/SemanticMediaWiki/src/Query/ProfileAnnotator/QueryProfileAnnotatorFactory.php on line 29 and defined in /.../w/extensions/SemanticMediaWiki/includes/Subobject.php on line 42

So far I only enabled the semantic extensions.

@kghbln kghbln added the bug label Dec 16, 2015

@mwjames

This comment has been minimized.

Contributor

mwjames commented Dec 16, 2015

I need more info as to why (and when == need an example) new Subobject( $query->getSubject()->getTitle() ), is empty because it shouldn't.

Before QueryProfileAnnotatorFactory (which is only called by AskParserFunction) is invoked the subject is set. [0]

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/parserhooks/AskParserFunction.php#L143-L145

@kghbln

This comment has been minimized.

Member

kghbln commented Dec 16, 2015

Currently this is all I get. I suspect that this script was not run for a very long time on this wiki.

@mwjames

This comment has been minimized.

Contributor

mwjames commented Dec 16, 2015

Currently this is all I get. I suspect that this script was not run for a very long time on this wiki.

Fixing the issue is not the problem but I'd like to know under which circumstances the case appears. Is it a borked subject, is it embedded somewhere?

$query->getSubject()->getTitle() should not lead to null Title and I'm eager to know why. Can you find out which id causes the failure and have a look at the content of the article?

@kghbln

This comment has been minimized.

Member

kghbln commented Dec 17, 2015

It is a bit strange. Adding the debug option to the script caused it to run further:

Running for storage: SMWSQLStore3
Removing marked for deletion entries.
306 IDs removed.
Rebuilding property pages.
(1/300 0%) Processing page Property:Website ...

further on with this run:

(83/32726) Processing ID 84 ...

ID 84 is "Property:To version". Changing this property to type text causes on the consecutive run to

Running for storage: SMWSQLStore3
Removing marked for deletion entries.
PHP Notice:  Undefined index: language in /.../w/extensions/SemanticMediaWiki/includes/parserhooks/DocumentationParserFunction.php on line 40
PHP Fatal error:  Call to a member function getValue() on null in /.../w/extensions/SemanticMediaWiki/includes/parserhooks/DocumentationParserFunction.php on line 40

Running the script a third time gives me an early exit as described in my initial post.

@mwjames

This comment has been minimized.

Contributor

mwjames commented Dec 17, 2015

Adding the debug option to the script caused it to run further:

Option debug doesn't interfere with the functionality, it only sets:

        if ( $this->hasOption( 'debug' ) ) {
            $maintenanceHelper->setGlobalToValue( 'wgShowExceptionDetails', true );
            $maintenanceHelper->setGlobalToValue( 'wgShowSQLErrors', true );
            $maintenanceHelper->setGlobalToValue( 'wgShowDBErrorBacktrace', true );
        }

"Property:To version". Changing this property to type text causes on the consecutive run to

This is different from what is mentioned above and makes no sense at all because [0], language is normally returned from Validator as default array index.

PHP Notice:  Undefined index: language in /.../w/extensions/SemanticMediaWiki/includes/parserhooks/DocumentationParserFunction.php on line 40
PHP Fatal error:  Call to a member function getValue() on null in /.../w/extensions/SemanticMediaWiki/includes/parserhooks/DocumentationParserFunction.php on line 40

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/2.3.x/includes/parserhooks/DocumentationParserFunction.php#L38-L40

The errors mentioned don't really make sense, so something is missing here. I have not enough information to make an analysis based on the given errors and guarding against null for the first case will not lead to an overall OK result as we might only fix the symptoms and not the cause.

Is this a new wiki? is this an old wiki converted? Is it only this specific wiki? Did you encountered this sort of issue on any other wiki?

@mwjames

This comment has been minimized.

Contributor

mwjames commented Dec 17, 2015

@kghbln In order to get more information let's try a different approach. Please add the following line to [0]:

    private function createQueryProfile( $query, $format, $duration ) {

        // Karsten is testing
        if ( $query->getSubject()->getTitle() === null ) {
            var_dump( $query->getSubject() );
            throw new \Exception( "Something is missing" );
        }

        $queryProfileAnnotatorFactory = $this->applicationFactory->newQueryProfileAnnotatorFactory();

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/2.3.x/includes/parserhooks/AskParserFunction.php#L191

@kghbln

This comment has been minimized.

Member

kghbln commented Dec 17, 2015

@mwjames This is the semantic-mediawiki.org wiki on the new server. I would first like to complete the move to the new server today and tackle this tomorrow. Stay tuned.

@kghbln

This comment has been minimized.

Member

kghbln commented Dec 17, 2015

It is starting to become an intense love story. Now I get Segmentation fault. Stay tuned.

@kghbln

This comment has been minimized.

Member

kghbln commented Dec 17, 2015

@mwjames after a bit of thinking it became obvious what is causing the error. I copied over big parts of the sandbox config to the new LocalSettings.php including

$smwgEnabledQueryDependencyLinksStore = true;

Since I added a lot of special properties and other stuff not present on the wiki before this setting must lead to issues. So first you have to rebuildData without this setting enabled and after that you do the next run with this setting turned on. Have not gotten to this point since the script is still running, however this should be it.

@mwjames

This comment has been minimized.

Contributor

mwjames commented Feb 18, 2016

$query->getSubject()->getTitle() should not lead to null Title and I'm eager to know why.

On a test wiki where I had experimented in the past with wgCapitalLinks I had two different pages issues/1219 and Issues/1219 and now when I run refreshLinks it would complain about:

[507d3507] [no req]   MWException from line 668 of ...\extensions\SemanticMediaWiki\includes\SemanticDat
a.php: Data for a subobject of Issues/1219 cannot be added to issues/1219.
Backtrace:
#0 ...\extensions\SemanticMediaWiki\includes\SemanticData.php(351): SMW\SemanticData->addSubSemanticData
(SMWContainerSemanticData)
#1 ...\extensions\SemanticMediaWiki\includes\parserhooks\AskParserFunction.php(221): SMW\SemanticData->a
ddPropertyObjectValue(SMW\DIProperty, SMWDIContainer)
#2 ...\extensions\SemanticMediaWiki\includes\parserhooks\AskParserFunction.php(185): SMW\AskParserFuncti
on->createQueryProfile(SMWQuery, string, integer)

After some research, I found that the AskParserFunction makes a $query->getSubject()->getTitle() where $query->getSubject() would contain the correct title namely issues/1219 but by the time getSubject()->getTitle() is called issues/1219 is turned into Issues/1219colliding with the expected issues/1219 (internally Title::makeTitleSafe is used).

So, it is possible that $query->getSubject()->getTitle() can return either null or something different based on Title::makeTitleSafe.

The exception of Data for a subobject of Issues/1219 cannot be added to issues/1219. or a possible null value makes sense which means we have to avoid the conversion applied by Title::makeTitleSafe.

mwjames added a commit that referenced this issue Feb 24, 2016

Merge pull request #1416 from SemanticMediaWiki/1318
Avoid Title::makeTitleSafe in QueryProfiler, refs #1318

@mwjames mwjames added this to the SMW 2.4 milestone Feb 24, 2016

@mwjames

This comment has been minimized.

Contributor

mwjames commented Feb 24, 2016

Catchable fatal error: Argument 1 passed to SMW\Subobject::__construct() is expected to be fixed by #1416 based on #1318 (comment).

@mwjames mwjames closed this Feb 24, 2016

@jamesmontalvo3

This comment has been minimized.

Contributor

jamesmontalvo3 commented Mar 4, 2016

I just experienced this issue, and will test the fix provided by #1416 shortly. My error:

(104/2532) Processing ID 105 ...
(105/2532) Processing ID 106 ...
PHP Catchable fatal error: Argument 1 passed to SMW\Subobject::__construct() must be an instance of Title, null given, called in /opt/meza/htdocs/mediawiki/extensions/SemanticMediaWiki/src/Query/ProfileAnnotator/QueryProfileAnnotatorFactory.php on line 29 and defined in /opt/meza/htdocs/mediawiki/extensions/SemanticMediaWiki/includes/Subobject.php on line 42

Catchable fatal error: Argument 1 passed to SMW\Subobject::__construct() must be an instance of Title, null given, called in /opt/meza/htdocs/mediawiki/extensions/SemanticMediaWiki/src/Query/ProfileAnnotator/QueryProfileAnnotatorFactory.php on line 29 and defined in /opt/meza/htdocs/mediawiki/extensions/SemanticMediaWiki/includes/Subobject.php on line 42

I'm trying to figure out what page is causing the issue (since I'm not sure I'll be able to roll to SMW 2.4 before it's released). Are the "Processing ID xyz" lines above referring to the smw_object_ids table? And if so, does the ID refer to the smw_id column in that table? Sometimes the output of rebuildData.php has mismatched IDs like:

(218502/231262) Processing ID 245983 ...

In this case, which number do I use?

If the error above is smw_id = 106 then The page is [[Project:Administrators]] and it's contents have one line of plain text with no links of any type (semantic or standard MW).

If the error above is smw_id = 105 then The page is [[Hurricane Preparedness]] and it's contents have nothing but external links. Browse properties shows only "Modification date".

If the error above means the 106th ID, knowing that some IDs are skipped, then doing SELECT * FROM smw_object_ids ORDER BY smw_id ASC LIMIT 1 OFFSET 105 shows that the page is [[Template:Nowrap]] and ...

If the error means the 105th ID is the issue, then SELECT * FROM smw_object_ids ORDER BY smw_id ASC LIMIT 1 OFFSET 104 shows [[Template:Navbar]] is the issue and ...

Template:Nowrap

<span class="nowrap">{{{1}}}</span><noinclude>
{{documentation}}
<!--interwikis/categories go inside doc-->
</noinclude>

Template:Navbar

<includeonly><span class="noprint plainlinks navbar" style="{{{style|}}}"><!--

-->{{#if:{{{mini|}}}{{{plain|}}}|<!--nothing-->|<!--else:
--><span style="{{{fontstyle|}}}">{{{text|This box:}}} </span>}}<!--

-->{{#if:{{{brackets|}}}|<span style="{{{fontstyle|}}}">&#91;</span>}}<!--

--><span style="white-space:nowrap;word-spacing:-.12em;"><!--
-->[[{{transclude|{{{1}}}}}|<span style="{{{fontstyle|}}}" title="View this template"><!--
-->{{#if:{{{mini|}}}|v|view}}</span>]]<!--

--><span style="{{{fontstyle|}}}">&#32;<b>&middot;</b>&#32;</span><!--
-->[[{{TALKPAGENAME:{{transclude|{{{1}}}}}}}|<span style="{{{fontstyle|}}}" title="Discuss this template"><!--
-->{{#if:{{{mini|}}}|d|talk}}</span>]]<!--

-->{{#if:{{{noedit|}}}|<!--nothing-->|<!--else:
--><span style="{{{fontstyle|}}}">&#32;<b>&middot;</b>&#32;</span><!--
-->[{{fullurl:{{transclude|{{{1}}}}}|action=edit}} <span style="{{{fontstyle|}}}" title="Edit this template"><!--
-->{{#if:{{{mini|}}}|e|edit}}</span>]}}<!--
--></span><!--

-->{{#if:{{{brackets|}}}|<span style="{{{fontstyle|}}}">&#93;</span>}}<!--

--></span></includeonly><noinclude>

{{documentation}}
</noinclude>

Template:documentation

<includeonly><div style="border: solid yellow 2px; margin: 10px; padding: 10px;">This is documentation for the template '''{{FULLPAGENAME}}'''. The documentation can be edited at [[{{FULLPAGENAME}}/doc]]</div>

{{{{PAGENAME}}/doc}}</includeonly>

Neither [[Template:Nowrap/doc]] nor [[Template:Navbar/doc]] exists. After creating these pages, with one-word content, the issue did not go away. Removing {{documentation}} from both templates had no change. Changing the contents of both templates to just "test" had no effect.

@jamesmontalvo3

This comment has been minimized.

Contributor

jamesmontalvo3 commented Mar 4, 2016

Running the following resolved the issue:

composer require mediawiki/semantic-media-wiki:@dev
php maintenance/update.php --quick
php extensions/SemanticMediaWiki/maintenance/rebuildData.php -d 5 -v --debug

When's the expected release of 2.4?

@kghbln

This comment has been minimized.

Member

kghbln commented Mar 4, 2016

@jamesmontalvo3 Thank you for testing the fix! The 2.4 release is currently scheduled for mid April

@mwjames

This comment has been minimized.

Contributor

mwjames commented Mar 4, 2016

When's the expected release of 2.4?

Well, I have at least three large PR's that I want to have done with 2.4 otherwise this dragging on and on ... (one is already a year old) which means a release will not happen before March.

The more people actually test the current @dev the easier is it for me to concentrate on finishing things I'd like to see done.

In this case, which number do I use?

Currently, there is not enough information to decide which table the ID makes a reference to but I hope #1433 can eliminate that ambiguity.

PS: MW 1.27 is currently not suitable, for details see #1295, #1424, and #1376.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment