MantisBT - NetSurf
View Issue Details
0002257NetSurfRISC OS-specificpublic2015-01-24 21:062015-03-10 23:40
ReporterChris Bell 
Assigned ToVincent Sanders 
PrioritynormalSeveritycrashReproducibilityalways
StatusclosedResolutionfixed 
PlatformPandaboardOSRISC OSOS Version5.21
Product Version3.2 
Target Version3.3Fixed in Version3.3 
Fixed in CI build #2565
Reported in CI build #
URL of problem pagehttp://www.JustGiving.com/ChrisBell-2014
Summary0002257: Webpage crashes NetSurf when !Cache is present
DescriptionI've viewed this webpage dozens of times in the last 2 months, but now it crashes NetSurf every time.
However it doesn't crash if I remove !Cache from Resources.
TagsNo tags attached.
Attached Filestxt Log.txt (98,257) 2015-01-24 21:06
https://bugs.netsurf-browser.org/mantis/file_download.php?file_id=237&type=bug
txt UYTBSFB.txt (119) 2015-01-29 09:17
https://bugs.netsurf-browser.org/mantis/file_download.php?file_id=240&type=bug
txt UYTBSFB_original.txt (565) 2015-01-29 17:09
https://bugs.netsurf-browser.org/mantis/file_download.php?file_id=242&type=bug

Notes
(0000583)
Vincent Sanders   
2015-01-28 18:02   
The backtrace indicates:

  ( 6a3680) pc: 400f0 lr: 338c4 sp: 6a3684 ^llcache_fetch_callback()
  ( 6a3690) pc: 338ac lr: 3630c sp: 6a3694 fetch_send_callback()
  ( 6a36c0) pc: 36288 lr: 1570ec sp: 6a36c4 ^fetch_curl_data()

curl.c::fetch_curl_data(char *data, size_t size, size_t nmemb, void *_f) {

....


    /* send data to the caller */
    msg.type = FETCH_DATA;
    msg.data.header_or_data.buf = (const uint8_t *) data;
    msg.data.header_or_data.len = size * nmemb;
    fetch_send_callback(&msg, f->fetch_handle);





fetch.c::void fetch_send_callback(const fetch_msg *msg, struct fetch *fetch)
{
    fetch->callback(msg, fetch->p);
}


llcache.c:static void llcache_fetch_callback(const fetch_msg *msg, void *p)
{

....

    case FETCH_DATA:
        /* Received some data */
        error = llcache_fetch_process_data(object,
                msg->data.header_or_data.buf,
                msg->data.header_or_data.len);
        break;




seems llcache_fetch_process_data() has been inlined by the compiler (its static and only ever used here once)

I do not recognise the code under the PC at the time of the crash in llcache_fetch_process_data() though

 Register dump at 006a9fb4:

    a1: 41 a2: 8de56db0 a3: 21 a4: 40
    v1: 74726f70 v2: 6c727520 v3: 6c672228 v4: 41
    v5: 8f322b50 v6: 8de56da0 sl: 6a31e0 fp: 6a3680
    ip: 6f6c6722 sp: 6a35e0 lr: 6d694000 pc: 49bef0
    cpsr: 20000110

 0049bedc : .D�� : e1844405 : ORR R4,R4,R5,LSL #8
  0049bee0 : %\�� : e1a05c25 : MOV R5,R5,LSR #24
  0049bee4 : .T�� : e1855406 : ORR R5,R5,R6,LSL #8
  0049bee8 : &l�� : e1a06c26 : MOV R6,R6,LSR #24
  0049beec : .d�� : e186640c : ORR R6,R6,R12,LSL #8

  0049bef0 : .�� : e483e004 : STR R14,[R3],#4

  0049bef4 : .@�� : e4834004 : STR R4,[R3],#4
  0049bef8 : .P�� : e4835004 : STR R5,[R3],#4
  0049befc : .`�� : e4836004 : STR R6,[R3],#4


(0000584)
Vincent Sanders   
2015-01-28 19:42   
objdump of content/llcache.o the inlined llcache_fetch_process_data() starts at 2fd8

nserror
llcache_fetch_process_data(llcache_object *object,
               const uint8_t *data,
               size_t len)
r0 = msg
r1 = object
r4 = object

    2fd8: e5913030 ldr r3, [r1, #48] ; 0x30
    2fdc: e3530002 cmp r3, 0000002

check for LLCACHE_FETCH_DATA

    2fe0: e5906004 ldr r6, [r0, #4]
    2fe4: e5905008 ldr r5, [r0, #8]
r6 = data
r5 = length
    2fe8: 0a000016 beq 3048 <llcache_fetch_callback+0x2a4>
    2fec: e591002c ldr r0, [r1, #44] ; 0x2c
    2ff0: ebfffffe bl 0 <fetch_http_code>
http_code (r0) = fetch_http_code(object->fetch.fetch);

    2ff4: e35000cb cmp r0, #203 ; 0xcb
    2ff8: 135000c8 cmpne r0, #200 ; 0xc8
    2ffc: 0a000131 beq 34c8 <llcache_fetch_callback+0x724>
if ((http_code != 200 && http_code != 203)
branches to rest of if statement

    34c4: eaffff2e b 3184 <llcache_fetch_callback+0x3e0>
    34c8: e5940008 ldr r0, [r4, #8]
    34cc: e3a01040 mov r1, #64 ; 0x40
    34d0: ebfffffe bl 0 <nsurl_has_component>
nsurl_has_component(object->url, NSURL_QUERY)

    34d4: e3500000 cmp r0, #0
    34d8: 0afffed1 beq 3024 <llcache_fetch_callback+0x280>
object->cache.expires == 0

    34dc: e5943054 ldr r3, [r4, #84] ; 0x54
    34e0: e3730001 cmn r3, #1
    34e4: 1afffece bne 3024 <llcache_fetch_callback+0x280>
object->cache.max_age == INVALID_AGE

    34e8: e594304c ldr r3, [r4, #76] ; 0x4c
    34ec: e3530000 cmp r3, #0
    34f0: 0afffec2 beq 3000 <llcache_fetch_callback+0x25c>
    34f4: eafffeca b 3024 <llcache_fetch_callback+0x280>



    3000: e594005c ldr r0, [r4, #92] ; 0x5c
    3004: ebfffffe bl 0 <free>
    3008: e284003c add r0, r4, #60 ; 0x3c
    300c: e3a01000 mov r1, #0
    3010: e3a02028 mov r2, #40 ; 0x28
    3014: ebfffffe bl 0 <memset>
    3018: e3e03000 mvn r3, #0
    301c: e5843050 str r3, [r4, #80] ; 0x50
    3020: e5843054 str r3, [r4, #84] ; 0x54
inline copy of llcache_invalidate_cache_control_data(object);

    3024: e5943064 ldr r3, [r4, #100] ; 0x64
    3028: e3530000 cmp r3, #0
if (object->candidate != NULL) {

    302c: 15932068 ldrne r2, [r3, #104] ; 0x68
    3030: 12422001 subne r2, r2, #1
    3034: 15832068 strne r2, [r3, #104] ; 0x68
    3038: 13a03000 movne r3, #0
    303c: 15843064 strne r3, [r4, #100] ; 0x64
object->candidate->candidate_count--;
object->candidate = NULL;
}

    3040: e3a03002 mov r3, 0000002
    3044: e5843030 str r3, [r4, #48] ; 0x30
object->fetch.state = LLCACHE_FETCH_DATA;

    3048: e5943010 ldr r3, [r4, #16]
    304c: e5941014 ldr r1, [r4, #20]
    3050: e0832005 add r2, r3, r5
    3054: e1520001 cmp r2, r1
    3058: 3a000101 bcc 3464 <llcache_fetch_callback+0x6c0>
if (object->source_len + len >= object->source_alloc) {

    305c: e2827801 add r7, r2, #65536 ; 0x10000
(r7) new_len = object->source_len + len + 64 * 1024;

    3060: e594000c ldr r0, [r4, #12]
    3064: e1a01007 mov r1, r7
    3068: ebfffffe bl 0 <realloc>
(r0) temp = realloc(object->source_data, new_len);

    306c: e3500000 cmp r0, #0
    3070: 0a0000f4 beq 3448 <llcache_fetch_callback+0x6a4>
if (temp == NULL) return NSERROR_NOMEM;

    3074: e584000c str r0, [r4, #12]
object->source_data = temp;

    3078: e5847014 str r7, [r4, #20]
object->source_alloc = new_len;

    307c: e5943010 ldr r3, [r4, #16]
    3080: ea0000f8 b 3468 <llcache_fetch_callback+0x6c4>

    3468: e0800003 add r0, r0, r3
    346c: e1a02005 mov r2, r5
    3470: e1a01006 mov r1, r6
    3474: ebfffffe bl 0 <memcpy>
memcpy(object->source_data + object->source_len, data, len);

    3478: e5943010 ldr r3, [r4, #16]
    347c: e0835005 add r5, r3, r5
    3480: e5845010 str r5, [r4, #16]
object->source_len += len;

    3484: eafffe91 b 2ed0 <llcache_fetch_callback+0x12c>
return NSERROR_OK;
(0000585)
Vincent Sanders   
2015-01-28 19:46   
ok this looks like memcpy() exploding because object->source_data() is NULL but object->source_alloc is non zero
(0000586)
Vincent Sanders   
2015-01-28 20:54   
Please can you attach the file SDFS::Panda.$.!BOOT.Resources.!Cache.Caches.Default.NetSurf.m.U.Y.T.UYTBSFB
(0000587)
Vincent Sanders   
2015-01-28 22:49   
please can you try with the most recent CI build (0002558 or later). This may fix the problem with broken cache metadata files which is why it is important to attach a copy of the file I already requested even if the issue is fixed.

The file name is
SDFS::Panda.$.!BOOT.Resources.!Cache.Caches.Default.NetSurf.m.U.Y.T.UYTBSFB
(0000588)
Chris Bell   
2015-01-29 16:52   
(Last edited: 2015-01-29 17:14)
Vincent... Thanks for your help.

I've just submitted the requested UYTBSFB file via this Bug Tracker interface (renamed UYTBSFB_original).

And I've just tried CI build 2560 and all is well. The page displays without any problems. Well done and thank you!

Chris.

(0000592)
Vincent Sanders   
2015-01-30 17:15   
The handling of incorrect metadata files was greatly improved which stopped the browser crashing from having bad internal cache data.

I have also analysed and fixed the underlying issue causing the failure to load the user provided cache data file (fallback time_t reading).

User also reports this is now working for them so closing bug as resolved.
(0000740)
Vincent Sanders   
2015-03-10 23:40   
Confirmed fixed in 3.3 release

Issue History
2015-01-24 21:06Chris BellNew Issue
2015-01-24 21:06Chris BellFile Added: Log.txt
2015-01-26 13:05Vincent SandersAssigned To => Vincent Sanders
2015-01-26 13:05Vincent SandersStatusnew => acknowledged
2015-01-28 18:02Vincent SandersNote Added: 0000583
2015-01-28 19:42Vincent SandersNote Added: 0000584
2015-01-28 19:46Vincent SandersNote Added: 0000585
2015-01-28 20:54Vincent SandersNote Added: 0000586
2015-01-28 20:54Vincent SandersStatusacknowledged => feedback
2015-01-28 22:49Vincent SandersNote Added: 0000587
2015-01-29 09:17Vincent SandersFile Added: UYTBSFB.txt
2015-01-29 16:52Chris BellNote Added: 0000588
2015-01-29 16:52Chris BellStatusfeedback => assigned
2015-01-29 17:09Chris BellFile Added: UYTBSFB_original.txt
2015-01-29 17:14Chris BellNote Edited: 0000588bug_revision_view_page.php?bugnote_id=588#r1404
2015-01-30 13:34Vincent SandersStatusassigned => confirmed
2015-01-30 17:15Vincent SandersFixed in CI build # => 2565
2015-01-30 17:15Vincent SandersURL of problem pagewww.JustGiving.com/ChrisBell-2014 => http://www.JustGiving.com/ChrisBell-2014
2015-01-30 17:15Vincent SandersNote Added: 0000592
2015-01-30 17:15Vincent SandersStatusconfirmed => resolved
2015-01-30 17:15Vincent SandersResolutionopen => fixed
2015-01-30 17:15Vincent SandersFixed in Version => 3.3
2015-01-30 17:15Vincent SandersTarget Version => 3.3
2015-03-10 23:40Vincent SandersNote Added: 0000740
2015-03-10 23:40Vincent SandersStatusresolved => closed