Crash on pdf-file open

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open a book (link to book download is here 
http://isohunt.com/torrent_details/389380981/C+Concurrency+in+Action?tab=summary
 )

What is the expected output?
ebookdroid is launched and the book is opened.

What do you see instead?
ebookdroid crashes and view is returned to file manager.

What version of the product are you using?
1.4.2

On what operating system?
android 2.3

What device are you using?
prestigio multipad

Please provide any additional information below.
Output from adb logcat is in attachment.

Original issue reported on code.google.com by ilin...@gmail.com on 13 May 2012 at 6:11

Attachments:

• log.txt

[GoogleCodeExporter]

How much memory does your tablet have? It seems that native MuPDF library can 
not allocate enough memory to decode page.

Original comment by Andrei.K...@gmail.com on 22 May 2012 at 8:26

[GoogleCodeExporter]

Hi I have similar problem with the following pdf file:
https://docs.google.com/open?id=0B6cRtp9ZMjUWUmpWWE1ENTZfVFU

When I try to open the file above the app will load one page of the pdf, 
and brings me back to the bookshelf screen before the 2nd page would appear.

My Phone is Sony Ericsson Xperia Pro - 512 MB Ram - Android 2.3.4 stock 
firmware.

I also attached log - saved with CatLog app.

Original comment by gilyenan...@gmail.com on 23 May 2012 at 3:00

Attachments:

• 2012-05-23-16-16-00.txt

[GoogleCodeExporter]

Manufacturer says, that device has 256 mb RAM.

I tried to load file mentioned by gilyenan...@gmail.com. Ebookdroid consumed 
all awailable memory and system killed it because of low mem. It had not 
crashed. Proof in attachment.

So, problem is indeed somewhere in native library, but it can be caused by some 
other bug.

Original comment by ilin...@gmail.com on 23 May 2012 at 6:01

Attachments:

• lowmem.log

[GoogleCodeExporter]

I've also tried your pdf file, for me it worked fine.
Do you think my issue is different from yours?
Or both of them is based on some memory leak?
(Too much memory usage for no real reason)

Original comment by gilyenan...@gmail.com on 23 May 2012 at 6:46

[GoogleCodeExporter]

@gilyenandras:
pls try the attached version with pagesInMemory=0.

Original comment by Alexander.V.Kasatkin@gmail.com on 24 May 2012 at 1:54

• Changed state: Discussion

Attachments:

• ebookdroid-1.4.3-dev-r1301.apk

[GoogleCodeExporter]

I've tried it, and works fine!
However when I set back pagesInMemory=2 it did the same as before.
With pagesInMemory=1 it crashed only after I reached the 2nd page.
(App was in landscape mode.)

Original comment by gilyenan...@gmail.com on 24 May 2012 at 3:11

[GoogleCodeExporter]

I have fixed the problem for myself.
Application crashes in file draw_simple_scale.c in function scale_row_from_temp 
somewhere in asm-code. I am not experienced in asm, so I can't narrow down the 
problem. Luckily, developers provided those scale_row_from_* functions written 
on C, so I just used them. And, my pdf-file opens correctly now. Hurray!

I will be glad to provide more information about problem, if you fill me with 
instructions, how to obtain it.

Original comment by ilin...@gmail.com on 24 May 2012 at 9:10

[GoogleCodeExporter]

@gilyenandras Yes with pagesinmemory other than 0 behaviour will be the same as 
before. We only changed for pagesinmemory=0 addig more aggresive memory freeing.

@ilin.pa can you provide your changes? We are trying to do only small fixes to 
used libraries. We just do not have free time to fix both our and third party 
code.

Original comment by Andrei.K...@gmail.com on 24 May 2012 at 9:53

[GoogleCodeExporter]

Patch is simple and dirty - I just commented asm implementations of functions.
It is to you to decide, use it or not.
I will try to post this bug in mupdf bugtracker later.

Original comment by ilin...@gmail.com on 24 May 2012 at 10:08

Attachments:

• draw_simple_scale.c.patch

[GoogleCodeExporter]

Am I right that you switched off all mupdf's arm optimizations? If that helped 
for your device than it can mean that that arm optimizations are not universal 
and can not be applied for all devices. I think we should remove all mupdf's 
arm optimizations. 

Original comment by Andrei.K...@gmail.com on 24 May 2012 at 10:11

[GoogleCodeExporter]

OK. I found bug:

    "ldr    r14,[r2, r4, LSL #2]!   @ r2 = contrib = index[index[row]+1]\n"

This instruction not available on all ARM hardware implementations.

I think we should remove all asm "optimizations" because GCC 4.6.3 produces 
mostly the same code, but without compatibility issues.

Original comment by Andrei.K...@gmail.com on 25 May 2012 at 8:00

[GoogleCodeExporter]

Great, I'm glad you found it.

Asm optimizations in libraries are always a tricky thing - every time I used 
some library, there was some problem with assembly code and I was forced to 
switch back to C/C++. Maybe I'm just unlucky.

Original comment by ilin...@gmail.com on 25 May 2012 at 8:24

[GoogleCodeExporter]

BTW, it can be patched out more easily: just remove     MY_MUPDF_CFLAGS +=  
-DARCH_ARM -DARCH_ARM_CAN_LOAD_UNALIGNED
from Android.mk for mupdf.

Original comment by Andrei.K...@gmail.com on 25 May 2012 at 8:32

[GoogleCodeExporter]

Ok, I will try, but I will be able to do it in 8-10 hours (or even tomorrow).
Anyway, will you submit a bug to mupdf project bugtrack?

Original comment by ilin...@gmail.com on 25 May 2012 at 9:04

[GoogleCodeExporter]

I think yes. I'll do some more tests and submit bug to mupdf bugtrack.

Original comment by Andrei.K...@gmail.com on 25 May 2012 at 9:52

• Changed state: Fixed