#609 Possible bug in reference list.


I just wrote this bug report for SVN 3325, please read till the end, cause in SVN3326 the
behavior changed.

TXS crashed for the third time in a row, when I was hovering over a list of references.
e.g. I cite several papers using \cite{paperA,paperB,paperC}.
Then I hover-over paperA and it gives me a short extract of the corresponding bib-file.
When I hover over a comma, however, TXS crashes with a assert failure in qstring.h line 688.
If I do anything except for pressing the "no,kill program" button, I have to kill the
Xorg window otherwise my computer freezes completely.

It is possible that this behavior only occurs after I have tried to compile a file
where I used a citation key which does not exist in the bibliography file.
I hope someone can reproduce this bug, as it is quite annoying that
TXS crashes completely.

TXS says it has a crash recovery file. I'd be willing to put it up here,
but i don't really know where it is located.

NOW THIS IS NEW: in SVN3326 hovering over a comma doesn't
crash TXS anymore, It gives me the normal pop-up window for a
citation and says that paperC} reference does not exist. Meaning
the last reference in the list including a curly bracket.

Hope this is helpful to reproduce the bug.

PS, thanx for fixing the autocomplete :-)

Btw, thanks for changing the autocomplete


  • Tim Hoffmann

    Tim Hoffmann - 2012-09-27

    I'd be very surprised if the changes between 3325 and 3326 affect the issue above, because they don't have anything to do with citations. Maybe it's just some other change in the usage or open files, which is not so obvious.

    The crash backtrace is written to the temp directory.

    Anyway I'll test the described behavior later.

  • Tim Hoffmann

    Tim Hoffmann - 2012-09-27

    Ok. It's easy to fix. But what should be displayed when hovering over a comma?
    - Nothing
    - The left citation
    - The right citation

    Likely the crash you encountered is initiated here, but finally pops up somewhere else. Currently the rest of the line was erronously interpreted as citation commands when hovering over a colon. So everything from the hover position on to the line end can have an influence if a crash occurs or not. Particularly colons brackets and spaces may change the behavior. I'd be interested also in finding the reason for the crash. Please provide the crashing example if you encounter it again.

  • Pat Schweitzer

    Pat Schweitzer - 2012-09-28

    I encountered the problem again... First, it was the SVN3326 behavior I described earlier.
    giving me a "missing citation". Then I changed a long citation key, somewhere in the middle,
    and puff, TXS crashed. Actually, I change it in a way, such that it refers to another cite-key
    in an unrelated .bib file (which is not open at the time.)

    I attached the backtrace. Is that the file you wanted? There are also four
    undo files for the documented that were open at that time. Do you also need those?

    I was trying to create a minimal example, but was unsuccessful so far. When doing this
    I changed the bib-file from one to another. The citations don't seem to get updated.

    I.e. \bibliography{test} (includes reference A)
    Chance to
    \bibliography{testi} (includes reference B)

    Hover over \cite{test,testi} still shows reference A. After TXS restart it shows reference B.

    And to answer your question, I would not display anything when hovering over a comma, but
    that's just a personal taste, I guess.

  • Benito van der Zander

    I attached the backtrace.

    The backtrace alone might not help much, since it only contains the
    addresses, not the functions, and they can
    be different on each system. (at least in txs on my computer your
    addresses are not found)

    What does print

    addr2line -C -f -e ./texstudio 0x81fbd75 0x8109fc9 0x8109bd9
    0x81fc506 0x81fc1f4 0x809fc18 0x8146f57 0x849561b

    It should convert the addresses to functions...

    There are also four undo files for the documented that were open at
    that time.

    It will create 3 different kinds of files, when it crashes:

    1. the backtrace you have attached

    2. these "undo files", which contain a log of all changes made to the

    3. the crash recovery files which contain a copy/backup of the entire
      document at the time of the crash.
      They are saved in the same directory as the document

    Do you also need those?

    That depends on the addr2line result ...

    On 09/28/2012 10:48 AM, SourceForge.net wrote:


  • Pat Schweitzer

    Pat Schweitzer - 2012-09-28

    here we go:

    print_backtrace(QString const&)
    txs_assert_x(char const, char const, char const, int)
    txs_assert(char const
    , char const, int)
    QString::at(int) const
    LatexEditorView::qt_metacall(QMetaObject::Call, int, void

  • Benito van der Zander


    but couldn't you click on "yes try to recover" in the error message to
    let it continue?
    that worked fine on my computer

    On 09/28/2012 01:08 PM, SourceForge.net wrote:


  • Tim Hoffmann

    Tim Hoffmann - 2012-09-28

    The toolitp is still incorrect when hovering over a colon. Also the code is a mixture of handling all bibIDs and just the one under the cursor. I'll take care of that later.

  • Pat Schweitzer

    Pat Schweitzer - 2012-09-28

    Thanks, I'll rebuild immediately after writing this message.

    I tried the button: "Yes, try to recover", but previously it has happened that my entire Xorg froze and that I couldn't even
    click a single button. And if a lot of things are opened on the desktop, restarting Xorg is quite annoying, therefore I preferred on only restart TXS. I will try, when not 15 documents are open... ;-)

    I'll leave the status open as I suppose you want to fix is after the tool-tip is fixed, right?

    Anyway, thanks again for fixing this rather annoying bug.

  • Benito van der Zander

    I tried the button: "Yes, try to recover", but previously it has happened
    that my entire Xorg froze and that I couldn't even
    pre or post r3169 (2012-08-15 18:08:31)?

    that revision should have fixed that freezing
    (by only printing the addresses. only since that version, calling
    addr2line become necessary...)

    On 09/28/2012 02:53 PM, SourceForge.net wrote:


  • Tim Hoffmann

    Tim Hoffmann - 2012-09-28

    fixed in rev. 3328


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks