Warning: mysqli_real_connect(): Headers and client library minor version mismatch. Headers:50625 Library:50543 in /sites/rockbox.org/flyspray/adodb/drivers/adodb-mysqli.inc.php on line 108 FS#8445 : Text viewer crashes when jumping to end of file



FS#8445 - Text viewer crashes when jumping to end of file

Attached to Project: Rockbox
Opened by Ori Avtalion (salty-horse) - Friday, 11 January 2008, 14:18 GMT
Last edited by Yoshihisa Uchida (Uchida) - Wednesday, 17 March 2010, 12:19 GMT
Task Type Bugs
Category Plugins
Status Closed
Assigned To Yoshihisa Uchida (Uchida)
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Load the following file in the text viewer:

Set these settings:
wordwrap: on.
line mode: reflow.
wide view: yes.
scrollbar: off.

Click the "end of file" key ("right" in sansa e200).
An error appears: "Data abort at <address>"
This task depends upon

Closed by  Yoshihisa Uchida (Uchida)
Wednesday, 17 March 2010, 12:19 GMT
Reason for closing:  Accepted
Additional comments about closing:  patch commits.
Comment by Robert Menes (RMenes379) - Friday, 18 January 2008, 14:28 GMT
Reproduced this bug on my 5.5G 30GB iPod video using all of the settings above.

Using SVN build r16096 and this file:
Comment by Nils Wallménius (nls) - Thursday, 24 January 2008, 18:17 GMT
Reproducible in sim too. The crash happens in common/unicode.c after iso_decode() is called from viewer.c:916 with a negative "count" parameter.
Comment by x (vmh) - Wednesday, 09 July 2008, 11:20 GMT
Reading the bug description I first thought this could be an easy bug to fix. But after looking into the code I think it is better to leave it to someone who is more familiar with the textviewer code to fix it and it is not only a Sansa e200 specific problem.

As Nils already mentioned the crash happens when iso_decode() is called with a negative count value. The problem is, THERE IS A MISMATCH BETWEEN PIXELWIDTH AND MEMORY POSITION.
While 'col' is in pixelwidth and 'k' is the index in the memory.

#define MAX_COLUMNS 64
unsigned char scratch_buffer[MAX_COLUMNS + 1];
scratch_buffer[k] = 0;
endptr = rb->iso_decode(scratch_buffer + col, utf8_buffer,
prefs.encoding, k-col);

When calling iso_decode() for the next screen 'col' has the value 176 (pixelwidth of the E200 screen).
The source 'scratch_buffer + col' will point to some undefined memory location and 'k-col' is negative (k=0..64).

I just wonder why the combination of line mode 'join' and 'wide view' doesn't crash, while it uses a similar code, but I would say it's also wrong there.

Comment by Yoshihisa Uchida (Uchida) - Monday, 12 January 2009, 03:09 GMT
I create the patch file.

Could you confirm operation?
Comment by Yoshihisa Uchida (Uchida) - Friday, 13 February 2009, 06:13 GMT
Applying this task's patch file after you apply  FS#9855 ,  FS#9892 ,  FS#9893 , or  FS#9898  fails.

Please use  FS#9899  (this task is closed) if you cannot mend the part in which the patch fails.
Comment by Yoshihisa Uchida (Uchida) - Saturday, 21 February 2009, 03:54 GMT
Because the patch file of  FS#9899  is old, I send a new patch.
Please apply the patch in order of  FS#9855 ,  FS#9892 ,  FS#9893 ,  FS#9898 ,  FS#9902 ,  FS#9853 ,  FS#9546  and this patch.

If you do not apply these patch files, this patch need not be applied.
Comment by Yoshihisa Uchida (Uchida) - Thursday, 05 March 2009, 13:33 GMT
Sync the viewer_2.patch.
Comment by Yoshihisa Uchida (Uchida) - Wednesday, 17 June 2009, 09:17 GMT
sync r21316
Comment by Teruaki Kawashima (teru) - Tuesday, 14 July 2009, 13:25 GMT
as far as i looked the source code and check the behavior, join mode and reflow mode seem to try to fit text to the screen size independent of view mode.
this means that scrolling left/right screen doesn't make sence. correct me if i'm wrong.
so, forcing narrow view would avoid crash when line mode is set to join or reflow.
i created a patch to do it.
any thoughts?
Comment by Yoshihisa Uchida (Uchida) - Wednesday, 24 February 2010, 11:00 GMT
I am sorry for very late the answer.

I think that it is a problem that invalidates the effect of WIDE mode.
I corrected that it did not abend like not changing the movement of original at WIDE mode.

I thought that it does not abend. But there are still a lot of problems in the display etc.
It is necessary to rewrite it completely, and I am doing the work now.