| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0002257 | NetSurf | RISC OS-specific | public | 2015-01-24 21:06 | 2015-03-10 23:40 | ||||
| Reporter | Chris Bell | ||||||||
| Assigned To | Vincent Sanders | ||||||||
| Severity | crash | Reproducibility | always | ||||||
| Status | closed | Resolution | fixed | ||||||
| Platform | Pandaboard | OS | RISC OS | OS Version | 5.21 | ||||
| Product Version | 3.2 | ||||||||
| Target Version | 3.3 | Fixed in Version | 3.3 | ||||||
| Summary | 0002257: Webpage crashes NetSurf when !Cache is present | ||||||||
| Description | I'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. | ||||||||
| Tags | No tags attached. | ||||||||
| Fixed in CI build # | 2565 | ||||||||
| Reported in CI build # | |||||||||
| URL of problem page | http://www.JustGiving.com/ChrisBell-2014 | ||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
Vincent Sanders (administrator) 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 |
|
Vincent Sanders (administrator) 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; |
|
Vincent Sanders (administrator) 2015-01-28 19:46 |
ok this looks like memcpy() exploding because object->source_data() is NULL but object->source_alloc is non zero |
|
Vincent Sanders (administrator) 2015-01-28 20:54 |
Please can you attach the file SDFS::Panda.$.!BOOT.Resources.!Cache.Caches.Default.NetSurf.m.U.Y.T.UYTBSFB |
|
Vincent Sanders (administrator) 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 |
Chris Bell (reporter) 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. |
|
Vincent Sanders (administrator) 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. |
|
Vincent Sanders (administrator) 2015-03-10 23:40 |
Confirmed fixed in 3.3 release |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-01-24 21:06 | Chris Bell | New Issue | |
| 2015-01-24 21:06 | Chris Bell | File Added: Log.txt | |
| 2015-01-26 13:05 | Vincent Sanders | Assigned To | => Vincent Sanders |
| 2015-01-26 13:05 | Vincent Sanders | Status | new => acknowledged |
| 2015-01-28 18:02 | Vincent Sanders | Note Added: 0000583 | |
| 2015-01-28 19:42 | Vincent Sanders | Note Added: 0000584 | |
| 2015-01-28 19:46 | Vincent Sanders | Note Added: 0000585 | |
| 2015-01-28 20:54 | Vincent Sanders | Note Added: 0000586 | |
| 2015-01-28 20:54 | Vincent Sanders | Status | acknowledged => feedback |
| 2015-01-28 22:49 | Vincent Sanders | Note Added: 0000587 | |
| 2015-01-29 09:17 | Vincent Sanders | File Added: UYTBSFB.txt | |
| 2015-01-29 16:52 | Chris Bell | Note Added: 0000588 | |
| 2015-01-29 16:52 | Chris Bell | Status | feedback => assigned |
| 2015-01-29 17:09 | Chris Bell | File Added: UYTBSFB_original.txt | |
| 2015-01-29 17:14 | Chris Bell | Note Edited: 0000588 | View Revisions |
| 2015-01-30 13:34 | Vincent Sanders | Status | assigned => confirmed |
| 2015-01-30 17:15 | Vincent Sanders | Fixed in CI build # | => 2565 |
| 2015-01-30 17:15 | Vincent Sanders | URL of problem page | www.JustGiving.com/ChrisBell-2014 => http://www.JustGiving.com/ChrisBell-2014 |
| 2015-01-30 17:15 | Vincent Sanders | Note Added: 0000592 | |
| 2015-01-30 17:15 | Vincent Sanders | Status | confirmed => resolved |
| 2015-01-30 17:15 | Vincent Sanders | Resolution | open => fixed |
| 2015-01-30 17:15 | Vincent Sanders | Fixed in Version | => 3.3 |
| 2015-01-30 17:15 | Vincent Sanders | Target Version | => 3.3 |
| 2015-03-10 23:40 | Vincent Sanders | Note Added: 0000740 | |
| 2015-03-10 23:40 | Vincent Sanders | Status | resolved => closed |
| Issue History |