Item767: AUTOINC in the title messes up merge and crashes
Priority: Normal
Current State: Closed
Released In: 1.0.1
Target Release: patch
Applies To: Engine
Component:
Branches:
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