Foswiki on GitHub is open for business! Next release meeting: Monday September 29, 1300Z

Item767: AUTOINC in the title messes up merge and crashes

Priority: CurrentState: AppliesTo: Component: WaitingFor:
Normal Closed Engine    
Go to http://foswiki.org/Sandbox/TestTopicAUTOINC0

Click raw edit

Enter
%WIKITOOLNAME%
Click Preview

Get:
Foswiki detected an internal error - please check your Foswiki logs and webserver logs for more information.  Can't call method "get" on an undefined value
Check your logs at ~0030 15-Jan-09

It is reproducible.

(Don't ask why I did that!) -- TimotheLitt - 15 Jan 2009


Can't reproduce on my machine.

-- MichaelDaum - 15 Jan 2009

It can not be a client issue; this is a server crash.

For what it's worth, note that that topic has a couple of attachments. It's not my topic and may have changed since; I never intended to save my little 'change'. But the server log will tell the story. Also note that the error may hint that the code is attempting to access missing or corrupt metatdata - perhaps about the attachments. It could also be an error path that doesn't set $meta. (I'd guess that some code tried a $meta->get with $meta undefined. Could be core or a plugin.)

This is all speculation - it should be an easy fix if someone can look at the server error log. No matter what the state of the metadata it shouldn't crash.

To protect the investigation against changes to the topic, here's a debug=raw view at ~1140 UTC - it still reproduces:
%META:TOPICINFO{author="ForrestSedgwick" date="1231891058" format="1.1" version="1.2"}%
%META:FILEATTACHMENT{name="news.jpg" attachment="news.jpg" attr="" comment="Obama" date="1231891058" path="news.jpg" size="2207" stream="IO::File=GLOB(0x2561e28)" tmpFilename="/var/tmp/CGItemp31788" user="ForrestSedgwick" version="1"}%

Oh, looks like there's another issue: when I saved this note with the verbatim metadata, the topic appeared to gain an attachment! verbatim ought to be quoting %META...

Here's an attempt to confuse that bug (I'll open another task for that):

%zzzMETA:TOPICINFO{author="ForrestSedgwick" date="1231891058" format="1.1" version="1.2"}%

%zzzMETA:FILEATTACHMENT{name="AnyKey2_ger.jpg" attachment="AnyKey2_ger.jpg" attr="" comment="" date="1231774968" path="C:\Dokumente und Einstellungen\Quasdorf\Eigene Dateien\Eigene Bilder\AnyKey2_ger.jpg" size="14373" stream="IO::File=GLOB(0x10fbc68)" tmpFilename="/var/tmp/CGItemp47982" user="HonkKnoh" version="1"}%
%zzzMETA:FILEATTACHMENT{name="news.jpg" attachment="news.jpg" attr="" comment="Obama" date="1231891058" path="news.jpg" size="2207" stream="IO::File=GLOB(0x2561e28)" tmpFilename="/var/tmp/CGItemp31788" user="ForrestSedgwick" version="1"}%

Good hunting.


This is quite an obscure case. It arises when editing a topic with AUTOINC in the title; in this example, TestTopicAUTOINC0. Because AUTOINCn is a reserved string, intended for the creation of sequentially numbered topics, it is assumed in the code that the edit will result in a topic called TestTopic0 (0 being the next number in the AUTOINC sequence). In this case the edit started on rev 2 of TestTopicAUTOINC0, but is saving to rev 1 of TestTopic0. This surprising rev sequence results in merge being fired, which tries to read the meta-data for TestTopic0 - which doesn't exist so, the read fails.

The immediate solution is to check that the topic actually exists before attempting a merge, but I would also encourage the authors of AUTOINC to reconsider how this is done.

Reduced to Normal because this is obscure.

-- CrawfordCurrie - 17 Jan 2009

ItemTemplate edit

Summary AUTOINC in the title messes up merge and crashes
ReportedBy TimotheLitt
Codebase 1.0.0
SVN Range Foswiki-1.0.0, Thu, 08 Jan 2009, build 1878
AppliesTo Engine
Component
Priority Normal
CurrentState Closed
WaitingFor
Checkins Foswikirev:2033
TargetRelease patch
ReleasedIn 1.0.1
Topic attachments
I Attachment Action Size Date Who Comment
AnyKey2_ger.jpgjpg AnyKey2_ger.jpg manage 14.0 K 12 Jan 2009 - 15:42 HonkKnoh  
Topic revision: r9 - 23 Feb 2009, KennethLavrsen
 
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement. Creative Commons License