Error when parsing the disassembled file

[silverwolfceh]

python view8.py disasm.tmp main.js --disassembled
Parsing disassembled file.
Traceback (most recent call last):
  File "C:\Users\soiba\Desktop\SW\github\View8\view8.py", line 57, in <module>
    main()
  File "C:\Users\soiba\Desktop\SW\github\View8\view8.py", line 50, in main
    all_func = disassemble(args.input_file, args.disassembled, args.path)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\soiba\Desktop\SW\github\View8\view8.py", line 17, in disassemble
    return parse_disassembled_file(out_name)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\soiba\Desktop\SW\github\View8\Parser\parse_v8cache.py", line 61, in parse_disassembled_file
    all_func = parse_file(out_name)
               ^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\soiba\Desktop\SW\github\View8\Parser\sfi_file_parser.py", line 189, in parse_file
    parse_shared_function_info(lines, "start")
  File "C:\Users\soiba\Desktop\SW\github\View8\Parser\sfi_file_parser.py", line 167, in parse_shared_function_info
    sfi.const_pool = parse_const_pool(line, lines, sfi.name)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\soiba\Desktop\SW\github\View8\Parser\sfi_file_parser.py", line 122, in parse_const_pool
    return parse_const_array(lines, func_name)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\soiba\Desktop\SW\github\View8\Parser\sfi_file_parser.py", line 113, in parse_const_array
    next_idx, value = parse_const_line(lines, func_name)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\soiba\Desktop\SW\github\View8\Parser\sfi_file_parser.py", line 82, in parse_const_line
    return var_idx, parse_shared_function_info(lines, value, func_name)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\soiba\Desktop\SW\github\View8\Parser\sfi_file_parser.py", line 167, in parse_shared_function_info
    sfi.const_pool = parse_const_pool(line, lines, sfi.name)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\soiba\Desktop\SW\github\View8\Parser\sfi_file_parser.py", line 122, in parse_const_pool
    return parse_const_array(lines, func_name)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\soiba\Desktop\SW\github\View8\Parser\sfi_file_parser.py", line 113, in parse_const_array
    next_idx, value = parse_const_line(lines, func_name)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\soiba\Desktop\SW\github\View8\Parser\sfi_file_parser.py", line 82, in parse_const_line
    return var_idx, parse_shared_function_info(lines, value, func_name)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\soiba\Desktop\SW\github\View8\Parser\sfi_file_parser.py", line 167, in parse_shared_function_info
    sfi.const_pool = parse_const_pool(line, lines, sfi.name)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\soiba\Desktop\SW\github\View8\Parser\sfi_file_parser.py", line 122, in parse_const_pool
    return parse_const_array(lines, func_name)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\soiba\Desktop\SW\github\View8\Parser\sfi_file_parser.py", line 113, in parse_const_array
    next_idx, value = parse_const_line(lines, func_name)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\soiba\Desktop\SW\github\View8\Parser\sfi_file_parser.py", line 70, in parse_const_line
    raise ValueError(f"Invalid constant line format: {var_line}")
ValueError: Invalid constant line format: Start ObjectBoilerplateDescription

Environment: v8 electron 10.6.194.26
Python 3.12 (look like not related to python)

It look like that parser not working for your patch of v8
disasm.zip

[sussyGaymer]

I'm not very educated on the V8 bytecode so I apologize in advance if any of my terminology is incorrect.

This appears to be an upstream issue with v8dasm/the V8 patch(es). In my example, this is the offending bytecode:

Constant pool (size = 7)
0xc43cb782ee1: [FixedArray] in OldSpace
 - map: 0x33d8e3c812e9 <Map>
 - length: 7
           0: 0x0c43cb782f29 
Start ObjectBoilerplateDescription
0xc43cb782f29: [ObjectBoilerplateDescription] in OldSpace
 - map: 0x33d8e3c82061 <Map>
 - length: 5
           0: 8
           1: 0x0c43cb782f61 <String[7]: #success>
           2: 0x33d8e3c81509 <Odd Oddball: uninitialized>
           3: 0x0c43cb782f79 <String[3]: #msg>
           4: 0x33d8e3c81509 <Odd Oddball: uninitialized>

End ObjectBoilerplateDescription

           1: 0x0c43cb782f61 <String[7]: #success>
           2: 0x0c43cb782f91 <String[9]: #_0x236e6d>
           3: 0x0c43cb782f79 <String[3]: #msg>
           4: 0x33d8e3c84609 <String[5]: #apply>
           5: 0x0c43cb782fb1 <String[9]: #_0x231b8f>
           6: 0x0c43cb782fd1 <String[9]: #_0x310a08>

You can see the Constant pool (size = 7) begin. However it's interrupted by a complete ObjectBoilerplateDescription object (I'm not sure if these things are called objects, sorry again for wrong terminology) and then the remaining 6 array elements are printed.

I should make an issue there, but I'll wait for @j4k0xb to reply in case this was caused by this repo's modifications to the patches.

[sussyGaymer]

Looking through disasm.tmp even more, I discovered things like this:

End BytecodeArray

End SharedFunctionInfo

Handler Table (size = 0)
Source Position Table (size = 15)
0x0c43cb783199 <ByteArray[15]>

End BytecodeArray

End SharedFunctionInfo

Handler Table (size = 0)
Source Position Table (size = 14)
0x0c43cb7831d1 <ByteArray[14]>

End BytecodeArray

End SharedFunctionInfo

Now, I see no logical way how this (ending a SharedFunctionInfo object 3 times in a row) makes sense, so I think different objects are being logged in parallel, therefore interrupting each other and creating this mess (see previous example).

[j4k0xb]

Edit: found the issue, the patch removed a line that the upstream has
The current way it works is by printing all disassembled objects recursively to the console, which is later parsed by regex (fails often)

Now, I see no logical way how this (ending a SharedFunctionInfo object 3 times in a row) makes sense

They're from different functions (which are in the constant pool)

[sussyGaymer]

Any ETA on the release of that?

[j4k0xb]

fixed, build again with the new patch