Page 1 of 2

Ticket #112 (defect) Fatal Error Code 3

Posted: 06 Oct 2006, 18:52
by seanodonnell
Thought I should post this hear as well as trac, so its easier to ask me for any clarifications that might be needed.

Fatal Error Code 3: [D001, Received reply is not XML]: when visiting prefs.php in 1.2.3-p1

Not entirely consistent, about 1 time in 20 the page renders without problems.

Using 1.2.3-p1 Using Firefox 1.5.07 Postgres database

?debug=1 output

# 15:41:59] selectTab: genConfig(NU: undefined)
# [15:41:59] confirm_feed_catchup => 0
# [15:41:59] feeds_sort_by_unread => 0
# [15:41:59] hide_read_feeds => 0
# [15:41:59] on_catchup_show_next_feed =>
# [15:41:59] daemon_refresh_only =>
# [15:41:59] feeds_frame_refresh => 600
# [15:41:59] daemon_enabled =>
# [15:41:59] toolbar_view_mode => adaptive
# [15:41:59] reading init-params...
# [15:41:59] sanity check ok
# [15:41:58] debug mode activated

Posted: 06 Oct 2006, 22:27
by fox
D001 means sanity check failure, which is same function for both main tt-rss and prefs. Do you see this only in preferences?

Try calling this URL:

Code: Select all


and see if it returns valid XML (you'll probably have to do this more than once if error only manifests itself sometimes - which is very weird).

Posted: 07 Oct 2006, 01:56
by seanodonnell
that works every time, and I tried the prefs page both before and after trying this, the preferences still fails the vast majority of the time.

Using firebug to have a look at the ajax call's , it appears that this call causes the problem


Its returning html that is definately not well formed xhtml, and the call looks like its expecting xml to be returned.

p.s. Im working on a bookmarklet for easy adding of rss feeds using rss autodetection, I have a prototype working, Im just putting a bit of polish on it.
With look I will be posting it on sunday night (gmt).



Posted: 07 Oct 2006, 09:31
by fox
Not really, pref-prefs is the preferences tab contents, it doesn't need to be valid xhtml (see prefslist_callback).

The really weird thing is I don't see how this call can cause D00x error, it can only be caused by sanity check (see backend_sanity_check_callback).

EDIT: Oh, and what version are you using? You can try importing empty schema and see if that works.

Posted: 07 Oct 2006, 18:42
by seanodonnell
Hmmm, I think I will install from scratch and try a clean schema, some truely bizarre stuff is happening now. Firefox crashes on the front page, but oddly enough if I visit it with mozilla 1.7.12 it still works... , as does the preferences page. I would say this is purely a problem with my copy of firefox, but it happened when browsing from work as well... Ill see if I can get to the bottom of this.

Posted: 07 Oct 2006, 20:53
by seanodonnell
Came up with a quicker idea, I tried the demo installation

gave me exactly the same error,

Can someone else try this with firefox 1.5.07 and tell me if they get the same problem?

Im running ubuntu 6.06, but I have seen the same problem with firefox on winxp from my ofice.

Posted: 07 Oct 2006, 23:56
by fox
I develop using on windows and it works for me. Maybe something is wrong with your browser settings?

Posted: 09 Oct 2006, 17:42
by seanodonnell
Tried it from here on windows wit from a vmware image. It worked there too. Ill test it from one or two friends ubuntu boxes and let you know what the result it.

Posted: 09 Oct 2006, 23:11
by seanodonnell
Just got confirmation from a debian unstable user with firefox,
he gets exactly the same error.

From what I can tell the call to pref-prefs is still using the callback from sanity check , which expects xml

Posted: 09 Oct 2006, 23:50
by seanodonnell
I fixed it :)

It looks like the confused callbacks where the problem

i replaced some of the existing requests and used prototypes Ajax.Request instead


function updatePrefsList() {

pars = "op=pref-prefs";
new Ajax.Request("backend.php",
method : 'get',
parameters: pars,
onSuccess: prefslist_callback

and that fixed it. The callback has some slight changes as well.

You can see my version of prefs.js at

Posted: 10 Oct 2006, 09:01
by fox
This is from the ticket:

The global xmlhttp object seems to be reusing callbacks even though they should have been changed.

I don't get it. Can you explain what callbacks does xmlhttp object reuse and how? I have an Ubuntu (Dapper) box too and can't reproduce this bug. :?

I mean, I can't just start arbitrarily changing application because of some behaviour that doesn't even manifest itself consistently in Firefox. For all I know, the bug can be somewhere else, for example, in an extension or some weirdly cached javascript file.

All tt-rss is based on one xmlhttp object (actually, two in the main interface) being used over and over again, why change in this one instance?

Posted: 10 Oct 2006, 09:26
by seanodonnell
i dont entirely get it either,

I know the app uses one xmlhttprequest and that seems to be part of the problem.

I put alerts in the two callbacks used on the prefs page while loading.
I expected that I would see the alert from one, and then the alert from the next.
Instead, what I saw was the alert from the one callback twice. firebug only shows two ajax calls, one to the sanity check, and one for the prefs content.

I cant figure out exactly what the root cause of the bug is, it seems like the browser is ignoring the instruction to change the callback of the xmlhttprequest object. Which I know sounds insane, but its happening anyway.

As I said, I have had this replicated by a friend on a debian stable box with the same version of firefox, but If you are not getting the bug report from anyone else I am happy enough for you to ignore it. I can just keep patching my own install.

What version of firefox are you running in dapper, as well?

Posted: 10 Oct 2006, 11:05
by fox
Yep, Can you try to run it with empty (e.g. default) Firefox profile? I'd really love to get to the bottom of this.

Posted: 11 Jan 2007, 16:38
by Guillaume Bour

I have the same problem.
Works with konqueror or Opera, but fails with my firefox.

So I try with a fresh profile. And it works...
I reinstalled my extensions one by one, and found the guilty one:

It's firebug BETA which make ttrss prefs fail (from, not mozilla addons page).

Hope it helps.

- Ubuntu dapper drake
- Firefox
- Firebug 1.0b8

Posted: 11 Jan 2007, 16:52
by fox
Well, I don't think browser extensions are supposed to break websites. Working around browser issues I can understand, but working around extensions is too much. :) Thanks for the info, I'll close the ticket then.