2019-01-22 03:03 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002257NetSurfRISC OS-specificpublic2015-03-10 23:40
ReporterChris Bell 
Assigned ToVincent Sanders 
SeveritycrashReproducibilityalways 
StatusclosedResolutionfixed 
PlatformPandaboardOSRISC OSOS Version5.21
Product Version3.2 
Target Version3.3Fixed in Version3.3 
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.
Fixed in CI build #2565
Reported in CI build #
URL of problem pagehttp://www.JustGiving.com/ChrisBell-2014
Attached Files
  • txt file icon Log.txt (98,257 bytes) 2015-01-24 21:06 -
    txt file icon Log.txt (98,257 bytes) 2015-01-24 21:06 +
  • txt file icon UYTBSFB.txt (119 bytes) 2015-01-29 09:17 -
    https://www.justgiving.com/jg-refresh/content/css/jquery-ui/jquery-ui.min.css?3a42528a2f531f52266bc17c7d8cceba306da642
    
    txt file icon UYTBSFB.txt (119 bytes) 2015-01-29 09:17 +
  • txt file icon UYTBSFB_original.txt (565 bytes) 2015-01-29 17:09 -
    https://www.justgiving.com/jg-refresh/content/css/jquery-ui/jquery-ui.min.css?3a42528a2f531f52266bc17c7d8cceba306da6422856514218437121421843714014HTTP/1.1 200 OK:Content-Length:5562Content-Type:text/cssLast-Modified:Fri, 31 Oct 2014 16:15:56 GMTAccept-Ranges:bytesETag:"08635f325f5cf1:34d90"Server:Microsoft-IIS/6.0P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"X-Powered-By:ASP.NETAccess-Control-Allow-Headers:Content-TypeDate:Wed, 21 Jan 2015 12:32:37 GMTVary:Accept-EncodingContent-Encoding:gzipConnection:Keep-Alive
    
    txt file icon UYTBSFB_original.txt (565 bytes) 2015-01-29 17:09 +

-Relationships
+Relationships

-Notes
Vincent Sanders

~0000583

Vincent Sanders (administrator)

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

~0000584

Vincent Sanders (administrator)

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

~0000585

Vincent Sanders (administrator)

ok this looks like memcpy() exploding because object->source_data() is NULL but object->source_alloc is non zero
Vincent Sanders

~0000586

Vincent Sanders (administrator)

Please can you attach the file SDFS::Panda.$.!BOOT.Resources.!Cache.Caches.Default.NetSurf.m.U.Y.T.UYTBSFB
Vincent Sanders

~0000587

Vincent Sanders (administrator)

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

~0000588

Chris Bell (reporter)

Last edited: 2015-01-29 17:14

View 2 revisions

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

~0000592

Vincent Sanders (administrator)

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

~0000740

Vincent Sanders (administrator)

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