Bug Hunting Session
Bug 48039 - Cross-references in Master Document report Error: Reference source not found
Summary: Cross-references in Master Document report Error: Reference source not found
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.6.1 rc
Hardware: All All
: high critical
Assignee: Caolán McNamara
URL:
Whiteboard: bibisected36 target:4.1.0 target:3.6....
Keywords:
Depends on:
Blocks: mab3.6
  Show dependency treegraph
 
Reported: 2012-03-29 03:10 UTC by nayk
Modified: 2014-01-29 21:17 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
example files for referencing problem (32.59 KB, application/zip)
2012-05-22 14:11 UTC, Wolfram Riedel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description nayk 2012-03-29 03:10:18 UTC
I noticed that master documents created in LO3.4 have now cross-references disrupted in LO3.5.
Comment 1 Wolfram Riedel 2012-05-20 02:49:37 UTC
I'm seeing this too using LO 3.5.3.2. Resolving cross-references in the master document that were set within included documents is somewhat unreliable, showing "Error: Reference source not found" for some but not all of the figure/table references (happens for me for about a dozen out of 50-60 refs total of which almost all are within the includes).

Somehow by fiddling around I already got LO twice to resolve all refs correctly. However, after saving/quitting/reopening/updating the master document the same refs are dangling again.
Comment 2 Wolfram Riedel 2012-05-20 04:09:36 UTC
The issue may be related to bug 35669 which was supposedly fixed, but has comments that it is still not working.
Comment 3 Petr Mladek 2012-05-22 02:06:08 UTC
It would help a lot if you could attach a test document and steps to reproduce. If it get's broken during safe, please attach the broken document and describe how to fix it.
Comment 4 Wolfram Riedel 2012-05-22 14:11:11 UTC
Created attachment 61986 [details]
example files for referencing problem

I have created an example master document and two documents that are included with links into the master. Each include has one table number and a reference to it. The refs are fine directly after adding the sections, they get saved correctly, and without updating the links on reopening, they are still fine. 

However as soon as I select "update all", both references get "Error: Reference source not found". Note, that this problem does not occurr when having only one include.
Comment 5 nayk 2012-05-23 03:23:22 UTC
Well, this is very annoying I hope it can be fixed in a relatively short time. How can v 3.5 be a final version if a basic feature like master document doesn't work properly? Shame! 

Cheers,
Nicola


On Tuesday, 22 May 2012 at 22:11, bugzilla-daemon@freedesktop.org wrote:

> https://bugs.freedesktop.org/show_bug.cgi?id=48039
> 
> --- Comment #4 from Wolfram Riedel <wolfram.riedel@isaco.de (mailto:wolfram.riedel@isaco.de)> 2012-05-22 14:11:11 PDT ---
> Created attachment 61986 [details]
> --> https://bugs.freedesktop.org/attachment.cgi?id=61986
> example files for referencing problem
> 
> I have created an example master document and two documents that are included
> with links into the master. Each include has one table number and a reference
> to it. The refs are fine directly after adding the sections, they get saved
> correctly, and without updating the links on reopening, they are still fine. 
> 
> However as soon as I select "update all", both references get "Error: Reference
> source not found". Note, that this problem does not occurr when having only one
> include.
> 
> -- 
> Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
> 
>
Comment 6 Petr Mladek 2012-05-28 03:09:19 UTC
Yup, the references get broken after you update them. Thanks a for the nice test case.

Michael, Cedric, could you please have a look?
Comment 7 Wolfram Riedel 2012-08-08 21:20:27 UTC
Just tried it with version 3.6.0.4 (Build ID: 932b512) on linux, the bug is still there.
Comment 8 nayk 2012-08-09 22:34:41 UTC
(In reply to comment #7)
> Just tried it with version 3.6.0.4 (Build ID: 932b512) on linux, the bug is
> still there.

Sigh! Same here, time ago I tried with a pre-rel 3.6 on mac and bug was still there. Hope this is going to be looked after soon.
Comment 9 nayk 2012-10-03 09:56:16 UTC
This bug is still present in 3.6.1. Does anyone know if this is going to be fixed anytime soon?
Comment 10 Julien Nabet 2012-11-10 17:26:24 UTC
On pc Debian x86-64 with master sources updated today I reproduced this problem.

Just some first research:
"Error: Reference source not found" is defined by STR_GETREFFLD_REFITEMNOTFOUND in sw/source/ui/utlui/initui.src
STR_GETREFFLD_REFITEMNOTFOUND is only used to declare aGetRefFld_RefItemNotFound variable here: sw/source/ui/utlui/initui.cxx

This variable is only used there:
void SwGetRefField::UpdateField( const SwTxtFld* pFldTxtAttr ) (sw/source/core/fields/reffld.cxx)

Then reading this:
    296     SwTxtNode* pTxtNd = SwGetRefFieldType::FindAnchor(
    297         pDoc, sSetRefName, nSubType, nSeqNo, &nNumStart, &nNumEnd
    298     );
    299     // not found?
    300     if ( !pTxtNd )
    301     {
    302         sTxt = ViewShell::GetShellRes()->aGetRefFld_RefItemNotFound;
    303         return ;
    304     }

FindAnchor method is line 831 of this same file.
Running gdb on all this showed me that if at the beginning nSeqNo was equal to 1, then it seems always equal to 0. Now is it normal or not? Why is it always 0?...
Comment 11 Joseph Ervin 2012-11-15 13:46:27 UTC
The cross-reference issues with master docs has plagued this application for almost a decade.  

The bug that has affected most of us in the staroffice/openoffice/libreoffice community over that time has been that cross references within a subdoc would scramble when the master doc is fully assembled.  So a cross reference of "see Table 3-1, below, on page 22", would be scrambled into "see Table 2-3, above, on page 11", or something similar.  It rendered cross references useless in projects using master docs.  

The biggest bummer is that Libreoffice seems now to have broken what has been a usable workaround for this issue for the past 9 years; the workaround being to create a custom counter variable name for each subdoc.  This has been easy to do simply by manually typing a cross-reference category name directly into the category field of the caption dialog box.  So instead of simply choosing "Table" from the drop-down, you type "fooTable" directly into the dialog.  This automatically creates a counter variable called "fooTable" and a paragraph style called "fooTable".   The created caption then says "fooTable 1-1: my text here".  

Then, you could just delete the "foo" from the caption text, leaving a caption of "Table 1-1: my text here".  Later a cross reference to this caption could be inserted elsewhere in the same subdoc selecting "fooTable 1-1" in the cross-reference dialog.  If you were cross-referencing "category and number", prior versions of Libreoffice and openoffice would correctly insert "Table 1-1" into the doc. 

With version 3.6.3.2, however, there seems to be a check that the "category" part of the caption text matches the name of the counter variable, and if not, then the category part of the caption is omitted from the cross-reference.  So in my example where I used "fooTable" as the counter variable and then just deleted "foo" from the caption, I find that I am unable to insert a proper cross reference that includes the category.  Trying to do so inserts only the number part of the cross reference, i.e. "1-1".  

Please fix cross references in master docs, and please, please, please, undo the change that broke this longstanding workaround.

Regards,

Joe
Comment 12 nomnex 2012-11-16 07:52:20 UTC
The problem I encounter using this workaround is the master document does not number the table or figure captions incementaly anymore (eg. from 1 to 500). The number range variables restart (from 1) in each sub-document.

How about you rename the captions accordingly eg. "Ch1-Figure1:" to avoid renaming them in LO 3.6.3.2?
Comment 13 Francisco 2012-11-27 03:36:44 UTC
I think this bug should be included in "most annoying.." bugtracker since there's information lost...
Comment 14 Francisco 2012-11-27 11:45:12 UTC
(In reply to comment #13)
> I think this bug should be included in "most annoying.." bugtracker since
> there's information lost...

Oops, I did't realize that it was already included in 3.5.
Comment 15 Joseph Ervin 2012-11-27 19:02:55 UTC
(In reply to comment #12)
> The problem I encounter using this workaround is the master document does
> not number the table or figure captions incementaly anymore (eg. from 1 to
> 500). The number range variables restart (from 1) in each sub-document.
> 

Hi nomnex, 

yes, the number ranges start over in each subdoc, as is to be expected, since they each use their own counter variable; the numbers are subdoc specific.  This is fine for me, however, because the document template design I've been using for a decade uses per-chapter numbering anyway, i.e. Figure 2-5 for the fifth figure in chapter 2.  So the workaround I described worked perfectly....until recently when LO broke it.  


> How about you rename the captions accordingly eg. "Ch1-Figure1:" to avoid
> renaming them in LO 3.6.3.2?

I don't understand what you're getting at here...

Joe
Comment 16 nomnex 2012-11-28 01:21:45 UTC
(In reply to comment #15)

> design I've been using for a decade uses per-chapter numbering anyway, i.e.
> Figure 2-5 for the fifth figure in chapter 2.

I did a quick try with heading numbered and numbrering caption by chapter. The chapter caption (figure 2-5: dummy image) is lost when I import the sub-doc in the master (figure 5: dummy image). It's an issue when I create an index of figures. Out of cursiosity, can I see your document for my reference?  
 
> > How about you rename the captions accordingly eg. "Ch1-Figure1:" to avoid
> > renaming them in LO 3.6.3.2?
> 
> I don't understand what you're getting at here...

FWIW, I was simply suggesting to name the "custom number range variable", in each sub-document, in a manner that you don't need to search for and replace them in the master. (e.g. sub1Figure, sub2Figure, etc.).
Comment 17 nomnex 2012-11-30 00:57:40 UTC
(In reply to comment #16)

> I did a quick try with heading numbered and numbrering caption by chapter.
> The chapter caption (figure 2-5: dummy image) is lost when I import the
> sub-doc in the master (figure 5: dummy image). 

Sry., that was my first try... I did not know I also had to "Number by chapter" in the master. Woraround works great (up to LO 3.6.3.2), as per Joe comment. Thanks.
Comment 18 Joseph Ervin 2012-12-20 19:19:12 UTC
Hello nomnex,

I just tried version  LibO 3.6.4 and the regression is there as well.

Now that you've reproduced the issue and seen how the longstanding workaround has been broken, can you give us any idea when this regression will be fixed?

I'm in the middle of a big 1000-page "master doc" project, and the timing of this regression could not be worse for me personally...

Joe
Comment 19 nayk 2012-12-21 09:41:50 UTC
I really want to support the request below. At least let us know ASAP when and if you are going to fix this. 

Thanks 


On Thursday, 20 December 2012 at 19:19, bugzilla-daemon@freedesktop.org wrote:

> 
> Comment # 18 (https://bugs.freedesktop.org/show_bug.cgi?id=48039#c18) on bug 48039 (https://bugs.freedesktop.org/show_bug.cgi?id=48039) from Joseph Ervin (mailto:joseph.ervin@oracle.com) 
> Hello nomnex, I just tried version LibO 3.6.4 and the regression is there as well. Now that you've reproduced the issue and seen how the longstanding workaround has been broken, can you give us any idea when this regression will be fixed? I'm in the middle of a big 1000-page "master doc" project, and the timing of this regression could not be worse for me personally... Joe
> 
> 
> You are receiving this mail because: 
> You reported the bug.
> 
> 
>
Comment 20 Francisco 2012-12-24 01:29:03 UTC
(In reply to comment #18)
> Hello nomnex,
> 
> I just tried version  LibO 3.6.4 and the regression is there as well.
> 
> Now that you've reproduced the issue and seen how the longstanding
> workaround has been broken, can you give us any idea when this regression
> will be fixed?
> 
> I'm in the middle of a big 1000-page "master doc" project, and the timing of
> this regression could not be worse for me personally...
> 
> Joe

I Don't know if I will be of any help but, this bug is affecting me also, although with a manuscript of ~250 pgs. 
What I'm doing right now is working with every subfile as always, but instead of a master I'm inserting those files in a new one, using "Insert -> File" option.

Regards, 

Francisco.
Comment 21 nayk 2013-02-12 10:31:57 UTC
Hi - is there any news about this bug? Has it been forgotten?

Thanks - nayk
Comment 22 Joel Madero 2013-02-12 22:33:52 UTC
I am moving this to 3.6 MAB as 3.5 is at end of life and therefore we're closing this meta tracker. 

@everyone - I will try to raise awareness to someone who might be able to fix this one. Thanks for your patience, apologies it's been so long
Comment 23 nayk 2013-02-13 09:38:59 UTC
Can u provide a link we can all check in order to see progresses on this bug?

Thanks
Comment 24 nomnex 2013-02-13 10:19:40 UTC
(In reply to comment #23)
> Can u provide a link we can all check in order to see progresses on this bug?

You are at the right place.

I made a comment yesterday on the mba3.5 thread #37361, to call for attention, because this bug is assigned to nobody. Thanks to Joel, we have some feedback.

As long this bug is assigned to no one, don't expect any change.

--nomnex
Comment 25 John Fisher 2013-03-15 17:36:52 UTC
In 4.0.1 on XUbuntu Quantal, a 250 p document as a master doc with each subdoc as a chapter or appendix. I too have been maintaining these books in this way for many years in OOO and now LO.

3.6x was broken as described in this bug report - "error reference not found"

4.0.1 seems to be working for caption contents, but figure numbering is broken.
Tables work correctly - each table caption is numbered "<chapter number>-<table number starting at 1 for each chapter>"
Figures however, are always "1-<figure number starting at 1 for each chapter>"

Should that be a separate bug report?
Comment 26 John Fisher 2013-03-15 18:00:11 UTC
(In reply to comment #25)
> In 4.0.1 on XUbuntu Quantal, a 250 p document as a master doc with each
> subdoc as a chapter or appendix. I too have been maintaining these books in
> this way for many years in OOO and now LO.
> 
> 3.6x was broken as described in this bug report - "error reference not found"
> 
> 4.0.1 seems to be working for caption contents, but figure numbering is
> broken.
> Tables work correctly - each table caption is numbered "<chapter
> number>-<table number starting at 1 for each chapter>"
> Figures however, are always "1-<figure number starting at 1 for each
> chapter>"
> 
> Should that be a separate bug report?

Belay that. "error reference not found" is back in 4.0.1. Its possible that deleting and re-creating the figure captions in the subdocs fixes it. Tables work fine.
Comment 27 John Fisher 2013-03-15 20:10:49 UTC
(In reply to comment #26)
> (In reply to comment #25)

> 
> Belay that. "error reference not found" is back in 4.0.1. Its possible that
> deleting and re-creating the figure captions in the subdocs fixes it. Tables
> work fine.

I am getting both types of bug: failure to cross-reference figure captions correctly in the masterdoc " error reference not found"
and
failure to number figure captions by chapter number in the master doc.
I did not completely test a brand new document - I am using old documents originally created years ago.
and 
The results are quite erratic. Some subdocs work some don't. A recreated subdoc didn't work.
Comment 28 Caolán McNamara 2013-04-11 15:29:32 UTC
this should be bibisectable with bibisect-3.6
Comment 29 Caolán McNamara 2013-04-11 15:36:34 UTC
source-hash-ce97851773a06103504972eb2771eecd7dd81e36

# bad: [aa062d7ec36c69c1aff1abf994a90c5f0987c5be] source-hash-d50f02bec4a70bd26a518e4e76f4a876454ab937
# good: [bba31ba417672c6f185a6875c813677e8ac44c86] source-hash-9a8d7e2a3f41f9e1c39c5634714a3a2b21776670
git bisect start 'latest' 'oldest'
# bad: [631e1335e3a9629152a2a4cb0f99304248299eb0] source-hash-bd6310886dc4351a8ac3ed3ee9a4f65d2a0e005c
git bisect bad 631e1335e3a9629152a2a4cb0f99304248299eb0
# bad: [078f3ebbba087e4ff9aa6ef26b9a4b0128850261] source-hash-8b55ef8898a39803e9c4a8cd6a271576389c0249
git bisect bad 078f3ebbba087e4ff9aa6ef26b9a4b0128850261
# bad: [3fe6f9e4a5d75e2a6f05f1fba212c33db30257d2] source-hash-4ff7252375b7b85eafbf176ca4e9184cc392d980
git bisect bad 3fe6f9e4a5d75e2a6f05f1fba212c33db30257d2
# good: [731fe8f30eae43e902b129fd1d9356e1ea665744] source-hash-43c7830b03d141ae11d8617c0fdabefa32dd243c
git bisect good 731fe8f30eae43e902b129fd1d9356e1ea665744
# bad: [4541b3234381241e171dcf6e34e638df0316237a] source-hash-a330f38093e2643a26239557050561afae9ff23d
git bisect bad 4541b3234381241e171dcf6e34e638df0316237a
# bad: [01679256aaddef65a77fccc945aa9ec06197640d] source-hash-ce97851773a06103504972eb2771eecd7dd81e36
git bisect bad 01679256aaddef65a77fccc945aa9ec06197640d
Comment 30 Caolán McNamara 2013-04-11 19:45:40 UTC
when modifying the sequence numbers of the subdocuments in order to disambiguate the fields we're using two slightly different algorithms for the get and set fields. The updated set fields are renumbered from the largest master document id + 1 onwards, while the updated get fields are renumbered with the lowest number that isn't already a master sequence number
Comment 31 Caolán McNamara 2013-04-11 20:08:53 UTC
I'll take this on the strict understanding that I'm fixing the (very good) provided test-case example of comment #4.

If #4 is fixed after this but something else still doesn't work, then a new bug is indicated, rather than reopening this one. Though of course if the comment #4 attachment still fails, then feel free to reopen.
Comment 32 Commit Notification 2013-04-11 20:13:38 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=74d942fb2396a268adfcc915e75b8b32fae851dc

Resolves: fdo#48039 use same algorithm for assigning get/set replacement ids



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 33 Caolán McNamara 2013-04-11 20:20:57 UTC
fixed on master, gerrit reviews for 3-6 and 4-0 pending
Comment 34 Commit Notification 2013-04-13 11:27:11 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1b1fe71be534fb05a11f741375e47f552e7a8914&h=libreoffice-3-6

Resolves: fdo#48039 use same algorithm for assigning get/set replacement ids


It will be available in LibreOffice 3.6.7.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 35 Commit Notification 2013-04-13 11:27:31 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9f3fad8804bfcd03e514d0c725c6380a16fb8f5a&h=libreoffice-4-0

Resolves: fdo#48039 use same algorithm for assigning get/set replacement ids


It will be available in LibreOffice 4.0.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 36 nayk 2013-05-17 10:29:27 UTC
Just tested 4.0.3 and it seems that this bug has been solved. Very many thanks!
Comment 37 nomnex 2013-05-17 14:39:39 UTC
(In reply to comment #36)
> Just tested 4.0.3 and it seems that this bug has been solved. Very many
> thanks!

It looks likes it's not? see: https://bugs.freedesktop.org/show_bug.cgi?id=35669#c45