2024-04-19 03:20 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002391NetSurfABENDpublic2016-02-16 14:07
ReporterRichard Porter 
Assigned ToDaniel Silverstone 
SeveritycrashReproducibilityalways 
StatusclosedResolutionfixed 
PlatformRiscPCOSRISC OSOS Version6.16
Product Version3.4 
Target Version3.4Fixed in Version3.4 
Summary0002391: Segfault (tracemail.com)
DescriptionSegmentation fault
Steps To ReproduceGo to problem page.
TagsNo tags attached.
Fixed in CI build #3333
Reported in CI build #3062
URL of problem pagehttp://www.traceemail.com/trace-email-header.html
Attached Files

-Relationships
+Relationships

-Notes
Dave Higton

~0001089

Dave Higton (developer)

Last edited: 2015-11-14 22:51

View 2 revisions

With CI#3062 it crashes on the BBxM but works fine on the Iyonix (both RO 5.22).

Also, on the BBxM, it works OK up to CI#2994 but fails from CI#2999, those being the closest ones I still have in my archive. The builds are only a couple of days apart.

Michael Drake

~0001099

Michael Drake (administrator)

Fatal signal received: Segmentation fault

Stack backtrace:

Running thread 0x70c808
  ( 715ee0) pc: 4e5c38 lr: 186164 sp: 715ee4 __write_backtrace()
  ( 715f08) pc: 1860e4 lr: 4e655c sp: 715f0c ro_gui_signal()
  ( 715f30) pc: 4e6544 lr: 4e6238 sp: 715f34 __unixlib_exec_sig()
  ( 715fa0) pc: 4e5d50 lr: 4e6b40 sp: 715fa4 __unixlib_raise_signal()
  ( 715fb0) pc: 4e6a44 lr: 8b448 sp: 714248 __h_cback()

  Register dump at 00715fb4:

    a1: e59ff400 a2: 4e4b9bd4 a3: e59ff400 a4: 0
    v1: 4e4a98a8 v2: e59ff418 v3: 4e468db8 v4: 0
    v5: 50000042 v6: 0 sl: 714208 fp: 714258
    ip: 71425c sp: 714248 lr: a008b448 pc: a024f0c8
    Mode USR, flags set: NzCvif

  0024f0b4 : .0\A0\E1 : e1a03000 : MOV R3,R0
  0024f0b8 : ..\90\E5 : e5900004 : LDR R0,[R0,#4]
  0024f0bc : ..R\E3 : e3520000 : CMP R2,#0
  0024f0c0 : ..\90. : 15901008 : LDRNE R1,[R0,#8]
  0024f0c4 : ..\93. : 05931008 : LDREQ R1,[R3,#8]
  0024f0c8 : ..\80. : 12800018 : ADDNE R0,R0,#&18 ; =24
  0024f0cc : . \A0\E1 : e1a0200d : MOV R2,R13
  0024f0d0 : .\F0\FF\EB : ebfff00d : BL &0024B10C
  0024f0d4 : ..P\E3 : e3500000 : CMP R0,#0

  ( 714258) pc: 24f0a4 lr: 8b448 sp: 71425c dom_string_length()
  ( 714274) pc: 8b3d0 lr: 11cc04 sp: 714278 dukky_html_text_area_element_value_getter()
  ( 714320) pc: 11c898 lr: 11d330 sp: 714324 duk_handle_call()
  ( 714334) pc: 11d2f4 lr: 132a00 sp: 714338 duk_call_method()
  ( 714398) pc: 132540 lr: 11ade0 sp: 71439c duk_hobject_getprop()
  ( 714410) pc: 119ae4 lr: 11c6b8 sp: 714414 duk__js_execute_bytecode_inner()
  ( 714494) pc: 11c26c lr: 11ce6c sp: 714498 duk_js_execute_bytecode()
  ( 714540) pc: 11c898 lr: 11d330 sp: 714544 duk_handle_call()
  ( 714554) pc: 11d2f4 lr: 13fe3c sp: 714558 duk_call_method()
  ( 714570) pc: 13fddc lr: 111454 sp: 714574 duk_eval_raw()
  ( 714584) pc: 11142c lr: 122a18 sp: 714588 eval_top_string()
  ( 714608) pc: 1228fc lr: 122cfc sp: 71460c duk_handle_safe_call()
  ( 714620) pc: 122ccc lr: 1120a4 sp: 714624 duk_safe_call()
  ( 714648) pc: 11203c lr: 168730 sp: 71464c js_exec()
  ( 7146cc) pc: 168464 lr: 24d444 sp: 7146d0 html_process_script()
  ( 7146dc) pc: 24d42c lr: 285708 sp: 7146e0 complete_script()
  ( 7146ec) pc: 2856dc lr: 28c030 sp: 7146f0 complete_script()
  ( 714718) pc: 28bf78 lr: 284cd4 sp: 71471c handle_generic_rcdata()
  ( 714730) pc: 284c38 lr: 27ba1c sp: 714734 hubbub_treebuilder_token_handler()
  ( 714748) pc: 27b9f4 lr: 280914 sp: 71474c hubbub_tokeniser_emit_token()
  ( 7147cc) pc: 2803c8 lr: 281fc8 sp: 7147d0 hubbub_tokeniser_handle_tag_name()
  ( 714a40) pc: 281b68 lr: 284b98 sp: 714a44 hubbub_tokeniser_run()
  ( 714a50) pc: 284b34 lr: 27a6b4 sp: 714a54 hubbub_tokeniser_setopt()
  ( 714a68) pc: 27a5a0 lr: 24e884 sp: 714a6c hubbub_parser_setopt()
  ( 714a80) pc: 24e864 lr: 167d88 sp: 714a84 dom_hubbub_parser_pause()
  ( 714ab4) pc: 167cac lr: cf538 sp: 714ab8 convert_script_sync_cb()
  ( 714afc) pc: cf4e0 lr: c2a5c sp: 714b08 hlcache_content_callback()
  ( 714b4c) pc: c29e8 lr: c2ea4 sp: 714b58 content_broadcast()
  ( 714bb4) pc: c2e48 lr: 111308 sp: 714bb8 content_set_done()
  ( 714bc8) pc: 1112f0 lr: c3148 sp: 714bcc javascript_convert()
  ( 714c30) pc: c2f7c lr: d1a50 sp: 714c34 content_llcache_callback()
  ( 714c68) pc: d18c0 lr: d1b48 sp: 714c6c llcache_object_notify_users()
  ( 714c80) pc: d1b1c lr: 199d90 sp: 714c84 llcache_catch_up_all_users()
  ( 714ca0) pc: 199d48 lr: a008 sp: 714ca4 schedule_run()
  ( 714fe8) pc: 9768 lr: 4f4904 sp: 714fec main()
Dave Higton

~0001100

Dave Higton (developer)

I don't understand why later versions malfunction on the cited URL, on some RISC OS platforms only. It doesn't make sense to me.

Also: I had a look at the git history, but I can't see the relationship between commits and build versions. There does not seem to be a 1:1 correspondence. Any pointers would be appreciated.
Vincent Sanders

~0001101

Vincent Sanders (administrator)

Likely the crashes on different platforms are different responses to the code changing value sin zero page as RISC OS does not protect that memory.
Daniel Silverstone

~0001121

Daniel Silverstone (administrator)

It looks like at least dom_html_text_area_element_get_value is odd and the exact behaviour of the .value and .defaultValue attributes for those need to be thought about.

Also the binding for fetching dom strings should probably decide if it should return "" when getting a NULL back from libdom, or if that's null or whatever.
Daniel Silverstone

~0001122

Daniel Silverstone (administrator)

As an aside, I also noticed that [TreatNullAs=EmptyString] is present on .value which suggests that we need to support that attribute too. All in all, the autogenerated code needs to cope with:

DOMString foo -> NULL -> "" and assigning null is an error
DOMString? foo -> NULL -> null
[TreatNullAs=EmptyString] DOMString foo -> NULL -> "" and assigning null is equiv to assigning "".

The question comes, how much of that belongs in nsgenbind and how much in libdom.
John-Mark Bell

~0001181

John-Mark Bell (administrator)

The logic of the libdom API is fairly simple: if the attribute you ask for does not exist, it will return NULL for its value. Otherwise, it will return whatever the value is set to (which might include the empty string). This permits the caller to distinguish between the case where an attribute exists, but its value is set to the empty string, and the case where the attribute does not exist. This doesn't exactly match the IDL expectations, so the binding layer will need to coerce answers appropriately.

As of http://git.netsurf-browser.org/nsgenbind.git/commit/?id=66e9aa8d66aae27098693554d26100417606164b nsgenbind will coerce NULL to "" on read (for generated attribute getters which return DOMString). It will return null in the case of attributes defined as DOMString?, although this is mostly moot as, in every case I've looked at, such IDL attributes are actually synthetic and will require specialised implementations. On write, the [TreatNullAs=EmptyString] extended attribute is adhered to. A test for the write case was introduced here: http://git.netsurf-browser.org/netsurf.git/commit/?id=25b88e42e6160c163f36f69226b4781c2fb56c92

No specialised behaviour has yet been implemented for HTMLTextArea's defaultValue or value attributes. I am, however, going to close this issue as the crash has been fixed as of CI#3333 (and the relative immaturity of the DOM/JS implementation means that there is currently little value in tracking specific behavioural defects in that area -- the DOM testsuites do a good job of that!).
Vincent Sanders

~0001235

Vincent Sanders (administrator)

Confirmed fixed in 3.4 release
+Notes

-Issue History
Date Modified Username Field Change
2015-11-14 01:08 Richard Porter New Issue
2015-11-14 01:08 Richard Porter File Added: nslog322.zip
2015-11-14 22:41 Dave Higton Note Added: 0001089
2015-11-14 22:51 Dave Higton Note Edited: 0001089 View Revisions
2015-11-17 10:48 Michael Drake Note Added: 0001099
2015-11-17 13:52 Dave Higton Note Added: 0001100
2015-11-17 16:35 Vincent Sanders Note Added: 0001101
2015-11-17 16:35 Vincent Sanders Status new => confirmed
2015-11-17 16:35 Vincent Sanders Product Version => 3.4
2015-11-27 11:26 Daniel Silverstone Note Added: 0001121
2015-11-27 11:26 Daniel Silverstone Assigned To => Daniel Silverstone
2015-11-27 11:47 Daniel Silverstone Note Added: 0001122
2016-02-01 21:14 John-Mark Bell Fixed in CI build # => 3333
2016-02-01 21:14 John-Mark Bell Note Added: 0001181
2016-02-01 21:14 John-Mark Bell Status confirmed => resolved
2016-02-01 21:14 John-Mark Bell Resolution open => fixed
2016-02-01 21:14 John-Mark Bell Fixed in Version => 3.4
2016-02-01 21:14 John-Mark Bell Target Version => 3.4
2016-02-16 14:07 Vincent Sanders Note Added: 0001235
2016-02-16 14:07 Vincent Sanders Status resolved => closed
+Issue History