profile
viewpoint
Ben Noordhuis bnoordhuis Deno Land Inc. The Netherlands

bnoordhuis/bspc 21

Quake 3 BSP-to-AAS compiler

bnoordhuis/amazing-graceful-fs 4

Like graceful-fs, but without eval() hacks and polyfills.

bnoordhuis/chicken-core 4

http://call-cc.org/

bnoordhuis/axis2-c 3

Apache Axis2/C is a Web services engine implemented in the C programming language.

bnoordhuis/chamfilter 3

block China and other South Asian countries at the firewall level

bnoordhuis/entityplus 3

just another quake 3 mod

bnoordhuis/c-ares 2

c-ares is a C library that performs DNS requests and name resolves asynchronously.

created tagbnoordhuis/v8-cmake

tag8.7.220.9

The V8 JavaScript engine, but built with CMake instead of GN - WIP

created time in 18 hours

push eventbnoordhuis/v8-cmake

Ben Noordhuis

commit sha a42ebfab89a56d0924570001f765eb1002b1263d

8.7.220.9

view details

push time in 18 hours

push eventbnoordhuis/v8-cmake

Ben Noordhuis

commit sha a42ebfab89a56d0924570001f765eb1002b1263d

8.7.220.9

view details

push time in 18 hours

created tagbnoordhuis/v8-cmake

tag8.6.395.17

The V8 JavaScript engine, but built with CMake instead of GN - WIP

created time in 18 hours

push eventbnoordhuis/v8-cmake

Ben Noordhuis

commit sha cda31cf5268036ee8c8076553da306749946529c

8.6.395.17

view details

push time in 18 hours

create barnchbnoordhuis/rustls

branch : sni

created branch time in 2 days

fork bnoordhuis/rustls

A modern TLS library in Rust

fork in 2 days

pull request commentlibuv/libuv

build: add asan checks

Landed in 97a90330.

gengjiawen

comment created time in 3 days

PR closed libuv/libuv

build: add asan checks

Fix https://github.com/libuv/libuv/issues/2999

+55 -1

8 comments

11 changed files

gengjiawen

pr closed time in 3 days

push eventlibuv/libuv

gengjiawen

commit sha 97a903309f79d79496a2a1f95cbcce21bfc2f76e

build: add asan checks Fixes: https://github.com/libuv/libuv/issues/2999 PR-URL: https://github.com/libuv/libuv/pull/2998 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

view details

push time in 3 days

issue closedlibuv/libuv

Possible memory leaks fix

I start a pr for asan checks in this repo. Looks current build is failure: https://github.com/libuv/libuv/pull/2998/checks?check_run_id=1139882930

2020-09-20T08:55:19.5837276Z ok 1 - platform_output # SKIP SUMMARY: AddressSanitizer: 30 byte(s) leaked in 1 allocation(s).
2020-09-20T08:55:19.5842474Z # exit code 1
2020-09-20T08:55:19.5845816Z # Output from process `platform_output`:
2020-09-20T08:55:19.5846623Z # uv_get_process_title: ./uv_run_tests_a
2020-09-20T08:55:19.5847275Z # uv_cwd: /home/runner/work/libuv/libuv/build
2020-09-20T08:55:19.5847887Z # uv_resident_set_memory: 19570688
2020-09-20T08:55:19.5848411Z # uv_uptime: 129.000000
2020-09-20T08:55:19.5848905Z # uv_getrusage:
2020-09-20T08:55:19.5849428Z #   user: 0 sec 4479 microsec
2020-09-20T08:55:19.5849957Z #   system: 0 sec 4479 microsec
2020-09-20T08:55:19.5850472Z #   page faults: 0
2020-09-20T08:55:19.5851043Z #   maximum resident set size: 19112
2020-09-20T08:55:19.5851685Z # uv_cpu_info:
2020-09-20T08:55:19.5852648Z #   model: Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz
2020-09-20T08:55:19.5853225Z #   speed: 2394
2020-09-20T08:55:19.5853687Z #   times.sys: 8690
2020-09-20T08:55:19.5854165Z #   times.user: 21870
2020-09-20T08:55:19.5854663Z #   times.idle: 83500
2020-09-20T08:55:19.5855133Z #   times.irq: 0
2020-09-20T08:55:19.5855596Z #   times.nice: 0
2020-09-20T08:55:19.5856484Z #   model: Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz
2020-09-20T08:55:19.5857059Z #   speed: 2394
2020-09-20T08:55:19.5857524Z #   times.sys: 13020
2020-09-20T08:55:19.5858008Z #   times.user: 30760
2020-09-20T08:55:19.5858481Z #   times.idle: 73270
2020-09-20T08:55:19.5858962Z #   times.irq: 0
2020-09-20T08:55:19.5859442Z #   times.nice: 0
2020-09-20T08:55:19.5859959Z # uv_interface_addresses:
2020-09-20T08:55:19.5860580Z #   name: lo
2020-09-20T08:55:19.5861020Z #   internal: 1
2020-09-20T08:55:19.5861504Z #   physical address: 00:00:00:00:00:00
2020-09-20T08:55:19.5861982Z #   address: 127.0.0.1
2020-09-20T08:55:19.5862431Z #   netmask: 255.0.0.0
2020-09-20T08:55:19.5862874Z #   name: eth0
2020-09-20T08:55:19.5863303Z #   internal: 0
2020-09-20T08:55:19.5863978Z #   physical address: 00:0d:3a:e2:24:77
2020-09-20T08:55:19.5864542Z #   address: 10.1.0.4
2020-09-20T08:55:19.5865113Z #   netmask: 255.255.0.0
2020-09-20T08:55:19.5865574Z #   name: lo
2020-09-20T08:55:19.5866030Z #   internal: 1
2020-09-20T08:55:19.5866525Z #   physical address: 00:00:00:00:00:00
2020-09-20T08:55:19.5870540Z #   address: ::1
2020-09-20T08:55:19.5870948Z #   netmask: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
2020-09-20T08:55:19.5871283Z #   name: eth0
2020-09-20T08:55:19.5871532Z #   internal: 0
2020-09-20T08:55:19.5871815Z #   physical address: 00:0d:3a:e2:24:77
2020-09-20T08:55:19.5872210Z #   address
2020-09-20T08:55:19.5872651Z # : fe80::20d:3aff:fee2:2477
2020-09-20T08:55:19.5873025Z #   netmask: ffff:ffff:ffff:ffff::
2020-09-20T08:55:19.5873332Z # uv_os_get_passwd:
2020-09-20T08:55:19.5874631Z #   euid: 1001
2020-09-20T08:55:19.5874857Z #   gid: 116
2020-09-20T08:55:19.5875096Z #   username: runner
2020-09-20T08:55:19.5875374Z #   shell: /bin/bash
2020-09-20T08:55:19.5875694Z #   home directory: /home/runner
2020-09-20T08:55:19.5876001Z # uv_os_getpid: 5410
2020-09-20T08:55:19.5876889Z # uv_os_getppid: 5409
2020-09-20T08:55:19.5877146Z # uv_os_uname:
2020-09-20T08:55:19.5877402Z #   sysname: Linux
2020-09-20T08:55:19.5877970Z #   release: 5.4.0-1025-azure
2020-09-20T08:55:19.5878499Z #   version: #25~18.04.1-Ubuntu SMP Sat Sep 5 15:28:57 UTC 2020
2020-09-20T08:55:19.5878817Z #   machine: x86_64
2020-09-20T08:55:19.5879037Z # 
2020-09-20T08:55:19.5879252Z # =================================================================
2020-09-20T08:55:19.5879666Z # ==5410==ERROR: LeakSanitizer: detected memory leaks
2020-09-20T08:55:19.5880043Z # 
2020-09-20T08:55:19.5880352Z # Direct leak of 30 byte(s) in 1 object(s) allocated from:
2020-09-20T08:55:19.5882281Z #     #0 0x7fe8031b7b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
2020-09-20T08:55:19.5883420Z #     #1 0x563cda93e4a1 in uv__malloc /home/runner/work/libuv/libuv/src/uv-common.c:77
2020-09-20T08:55:19.5884211Z #     #2 0x563cda94ba45 in uv__getpwuid_r /home/runner/work/libuv/libuv/src/unix/core.c:1200
2020-09-20T08:55:19.5884950Z #     #3 0x563cda94be8b in uv_os_get_passwd /home/runner/work/libuv/libuv/src/unix/core.c:1245
2020-09-20T08:55:19.5886024Z #     #4 0x563cda8bc49c in run_test_platform_output /home/runner/work/libuv/libuv/test/test-platform-output.c:149
2020-09-20T08:55:19.5886671Z #     #5 0x563cda830942 i
2020-09-20T08:55:19.5887104Z # n run_test_part /home/runner/work/libuv/libuv/test/runner.c:376
2020-09-20T08:55:19.5887917Z #     #6 0x563cda82d9c4 in main /home/runner/work/libuv/libuv/test/run-tests.c:68
2020-09-20T08:55:19.5888732Z #     #7 0x7fe8026e3b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
2020-09-20T08:55:19.5889183Z # 
2020-09-20T08:55:19.5889648Z # SUMMARY: AddressSanitizer: 30 byte(s) leaked in 1 allocation(s).
2020-09-20T08:55:19.6045062Z ok 2 - active
2020-09-20T08:55:19.6232107Z ok 3 - async
2020-09-20T08:55:19.6410265Z ok 4 - async_null_cb
2020-09-20T08:55:19.6563975Z ok 5 - async_ref
2020-09-20T08:55:19.7715872Z ok 6 - barrier_1
2020-09-20T08:55:19.8870037Z ok 7 - barrier_2
2020-09-20T08:55:19.9012979Z ok 8 - barrier_3
2020-09-20T08:55:20.0265486Z ok 9 - barrier_serial_thread
2020-09-20T08:55:20.0392157Z ok 10 - barrier_serial_thread_single
2020-09-20T08:55:20.5647747Z ok 11 - callback_stack
2020-09-20T08:55:20.5812438Z ok 12 - check_ref
2020-09-20T08:55:20.5941001Z ok 13 - close_fd
2020-09-20T08:55:20.6098726Z ok 14 - close_order
2020-09-20T08:55:20.6355259Z ok 15 - closed_fd_events
2020-09-20T08:55:20.6475091Z ok 16 - condvar_1
2020-09-20T08:55:20.6672205Z ok 17 - condvar_2
2020-09-20T08:55:20.6878078Z ok 18 - condvar_3
2020-09-20T08:55:20.7069538Z ok 19 - condvar_4
2020-09-20T08:55:20.8186574Z ok 20 - condvar_5
2020-09-20T08:55:20.8329988Z ok 21 - connect_unspecified
2020-09-20T08:55:20.8470469Z ok 22 - connection_fail
2020-09-20T08:55:20.9588030Z ok 23 - connection_fail_doesnt_auto_close
2020-09-20T08:55:20.9727922Z ok 24 - cwd_and_chdir
2020-09-20T08:55:20.9872103Z ok 25 - default_loop_close
2020-09-20T08:55:23.0038202Z ok 26 - delayed_accept
2020-09-20T08:55:23.0189775Z ok 27 - dlerror
2020-09-20T08:55:23.0327232Z ok 28 - eintr_handling
2020-09-20T08:55:23.3024912Z ok 29 - embed
2020-09-20T08:55:23.3180596Z ok 30 - emfile
2020-09-20T08:55:23.3378305Z ok 31 - env_vars
2020-09-20T08:55:23.3733901Z ok 32 - error_message # SKIP SUMMARY: AddressSanitizer: 23 byte(s) leaked in 1 allocation(s).
2020-09-20T08:55:23.7022341Z ok 33 - fork_fs_events_child
2020-09-20T08:55:24.0630228Z ok 34 - fork_fs_events_child_dir
2020-09-20T08:55:24.1907325Z ok 35 - fork_fs_events_file_parent_child
2020-09-20T08:55:24.2149534Z ok 36 - fork_signal_to_child
2020-09-20T08:55:24.2425164Z ok 37 - fork_signal_to_child_closed
2020-09-20T08:55:24.2701136Z ok 38 - fork_socketpair
2020-09-20T08:55:24.2923039Z ok 39 - fork_socketpair_started
2020-09-20T08:55:24.3338420Z ok 40 - fork_threadpool_queue_work_simple
2020-09-20T08:55:24.3589134Z ok 41 - fork_timer
2020-09-20T08:55:24.3782054Z ok 42 - fs_access
2020-09-20T08:55:24.4150593Z ok 43 - fs_async_dir
2020-09-20T08:55:24.4473890Z ok 44 - fs_async_sendfile
2020-09-20T08:55:24.4778042Z ok 45 - fs_async_sendfile_nodata
2020-09-20T08:55:24.5022893Z ok 46 - fs_chmod
2020-09-20T08:55:24.5344229Z ok 47 - fs_chown
2020-09-20T08:55:24.6653212Z not ok 48 - fs_copyfile
2020-09-20T08:55:24.6653960Z # exit code 134
2020-09-20T08:55:24.6654467Z # Output from process `fs_copyfile`:
2020-09-20T08:55:24.6655469Z # Assertion failed in /home/runner/work/libuv/libuv/test/test-fs-copyfile.c on line 138: r == 0
2020-09-20T08:55:24.7961976Z ok 49 - fs_event_close_in_callback
2020-09-20T08:55:24.8103366Z ok 50 - fs_event_close_with_pending_event
2020-09-20T08:55:24.8244523Z ok 51 - fs_event_error_reporting
2020-09-20T08:55:24.8506589Z ok 52 - fs_event_getpath
2020-09-20T08:55:24.8642042Z ok 53 - fs_event_immediate_close
2020-09-20T08:55:24.8797467Z ok 54 - fs_event_no_callback_after_close
2020-09-20T08:55:24.8948677Z ok 55 - fs_event_no_callback_on_close
2020-09-20T08:55:24.9069916Z ok 56 - fs_event_ref
2020-09-20T08:55:24.9192642Z ok 57 - fs_event_start_and_close
2020-09-20T08:55:25.0700682Z ok 58 - fs_event_watch_dir
2020-09-20T08:55:25.0882068Z ok 59 - fs_event_watch_dir_recursive # SKIP Recursive directory watching not supported on this platform.
2020-09-20T08:55:25.3027787Z ok 60 - fs_event_watch_file
2020-09-20T08:55:26.6692797Z ok 61 - fs_event_watch_file_current_dir
2020-09-20T08:55:26.8840554Z ok 62 - fs_event_watch_file_exact_path
2020-09-20T08:55:27.0226326Z not ok 63 - fs_event_watch_file_twice
2020-09-20T08:55:27.0226677Z # exit code 134
2020-09-20T08:55:27.0226987Z # Output from process `fs_event_watch_file_twice`:
2020-09-20T08:55:27.0229399Z # Assertion failed in /home/runner/work/libuv/libuv/test/test-fs-event.c on line 686: 0 == uv_fs_event_start(watchers + 0, fail_cb, path, 0)
2020-09-20T08:55:27.0362647Z ok 64 - fs_event_watch_invalid_path
2020-09-20T08:55:27.0832836Z ok 65 - fs_file_async
2020-09-20T08:55:27.1138790Z ok 66 - fs_file_loop
2020-09-20T08:55:27.1460561Z ok 67 - fs_file_nametoolong
2020-09-20T08:55:27.1747297Z ok 68 - fs_file_noent
2020-09-20T08:55:27.1938057Z ok 69 - fs_file_open_append
2020-09-20T08:55:27.2137090Z ok 70 - fs_file_pos_after_op_with_offset
2020-09-20T08:55:27.2268908Z ok 71 - fs_file_sync
2020-09-20T08:55:27.2421797Z ok 72 - fs_file_write_null_buffer
2020-09-20T08:55:27.2732095Z ok 73 - fs_fstat
2020-09-20T08:55:27.2930300Z ok 74 - fs_futime
2020-09-20T08:55:27.3082393Z ok 75 - fs_get_system_error
2020-09-20T08:55:27.3218519Z ok 76 - fs_lutime
2020-09-20T08:55:27.3409118Z ok 77 - fs_mkdtemp
2020-09-20T08:55:27.3585798Z ok 78 - fs_mkstemp
2020-09-20T08:55:27.3737017Z ok 79 - fs_null_req
2020-09-20T08:55:27.4024834Z ok 80 - fs_open_dir
2020-09-20T08:55:27.4442719Z ok 81 - fs_partial_read
2020-09-20T08:55:27.4686924Z ok 82 - fs_partial_write
2020-09-20T08:55:27.9854838Z ok 83 - fs_poll
2020-09-20T08:55:28.0148889Z ok 84 - fs_poll_close_request
2020-09-20T08:55:28.0494200Z ok 85 - fs_poll_close_request_multi_start_stop
2020-09-20T08:55:28.0915319Z ok 86 - fs_poll_close_request_multi_stop_start
2020-09-20T08:55:28.1216275Z ok 87 - fs_poll_close_request_stop_when_active
2020-09-20T08:55:28.1540215Z ok 88 - fs_poll_getpath
2020-09-20T08:55:28.1863944Z ok 89 - fs_poll_ref
2020-09-20T08:55:28.3134650Z not ok 90 - fs_read_bufs
2020-09-20T08:55:28.3135494Z # exit code 134
2020-09-20T08:55:28.3136044Z # Output from process `fs_read_bufs`:
2020-09-20T08:55:28.3137336Z # Assertion failed in /home/runner/work/libuv/libuv/test/test-fs.c on line 3042: 0 <= uv_fs_open(NULL, &open_req1, "test/fixtures/lorem_ipsum.txt", O_RDONLY | add_flags, 0, NULL)
2020-09-20T08:55:28.3424232Z ok 91 - fs_read_dir
2020-09-20T08:55:28.3575675Z ok 92 - fs_read_file_eof
2020-09-20T08:55:28.3736145Z ok 93 - fs_read_write_null_arguments
2020-09-20T08:55:28.4107987Z ok 94 - fs_readdir_empty_dir
2020-09-20T08:55:28.5420720Z not ok 95 - fs_readdir_file
2020-09-20T08:55:28.5421479Z # exit code 134
2020-09-20T08:55:28.5422105Z # Output from process `fs_readdir_file`:
2020-09-20T08:55:28.5423150Z # Assertion failed in /home/runner/work/libuv/libuv/test/test-fs-readdir.c on line 244: r == UV_ENOTDIR
2020-09-20T08:55:28.5686525Z ok 96 - fs_readdir_non_empty_dir
2020-09-20T08:55:28.5955282Z ok 97 - fs_readdir_non_existing_dir
2020-09-20T08:55:28.6178309Z ok 98 - fs_readlink
2020-09-20T08:55:28.6500293Z ok 99 - fs_realpath
2020-09-20T08:55:28.6639364Z ok 100 - fs_rename_to_existing_file
2020-09-20T08:55:28.6830546Z ok 101 - fs_scandir_empty_dir
2020-09-20T08:55:28.8044193Z not ok 102 - fs_scandir_file
2020-09-20T08:55:28.8044917Z # exit code 134
2020-09-20T08:55:28.8045456Z # Output from process `fs_scandir_file`:
2020-09-20T08:55:28.8046453Z # Assertion failed in /home/runner/work/libuv/libuv/test/test-fs.c on line 2847: r == UV_ENOTDIR
2020-09-20T08:55:28.8260925Z ok 103 - fs_scandir_non_existent_dir
2020-09-20T08:55:28.8436054Z ok 104 - fs_stat_missing_path
2020-09-20T08:55:28.8698902Z ok 105 - fs_statfs
2020-09-20T08:55:28.8921198Z ok 106 - fs_symlink
2020-09-20T08:55:28.9067471Z ok 107 - fs_symlink_dir
2020-09-20T08:55:28.9211771Z ok 108 - fs_unlink_readonly
2020-09-20T08:55:28.9493108Z ok 109 - fs_utime
2020-09-20T08:55:28.9717169Z ok 110 - fs_write_alotof_bufs
2020-09-20T08:55:28.9972690Z ok 111 - fs_write_alotof_bufs_with_offset
2020-09-20T08:55:29.0099148Z ok 112 - fs_write_multiple_bufs
2020-09-20T08:55:29.0263156Z ok 113 - get_currentexe
2020-09-20T08:55:29.0408565Z ok 114 - get_loadavg
2020-09-20T08:55:29.0573484Z ok 115 - get_memory
2020-09-20T08:55:29.0756732Z ok 116 - get_osfhandle_valid_handle
2020-09-20T08:55:29.0931999Z ok 117 - get_passwd
2020-09-20T08:55:29.1125084Z ok 118 - getaddrinfo_basic
2020-09-20T08:55:29.1281628Z ok 119 - getaddrinfo_basic_sync
2020-09-20T08:55:29.1542317Z ok 120 - getaddrinfo_concurrent
2020-09-20T08:55:29.2044259Z ok 121 - getaddrinfo_fail
2020-09-20T08:55:29.2192629Z ok 122 - getaddrinfo_fail_sync
2020-09-20T08:55:29.2347507Z ok 123 - gethostname
2020-09-20T08:55:29.2666938Z ok 124 - getnameinfo_basic_ip4
2020-09-20T08:55:29.2818601Z ok 125 - getnameinfo_basic_ip4_sync
2020-09-20T08:55:29.3146594Z ok 126 - getnameinfo_basic_ip6
2020-09-20T08:55:29.3303545Z ok 127 - getsockname_tcp
2020-09-20T08:55:29.3467959Z ok 128 - getsockname_udp
2020-09-20T08:55:29.3634120Z ok 129 - getters_setters
2020-09-20T08:55:29.3788636Z ok 130 - gettimeofday
2020-09-20T08:55:29.3910880Z ok 131 - handle_fileno
2020-09-20T08:55:29.4024294Z ok 132 - handle_type_name
2020-09-20T08:55:29.4172705Z ok 133 - has_ref
2020-09-20T08:55:29.4317803Z ok 134 - homedir
2020-09-20T08:55:32.8287997Z ok 135 - hrtime
2020-09-20T08:55:32.8427401Z ok 136 - idle_ref
2020-09-20T08:55:32.9048007Z ok 137 - idle_starvation
2020-09-20T08:55:32.9191648Z ok 138 - idna_toascii
2020-09-20T08:55:32.9314347Z ok 139 - ip4_addr
2020-09-20T08:55:32.9471708Z ok 140 - ip6_addr_link_local
2020-09-20T08:55:32.9619871Z ok 141 - ip6_pton
2020-09-20T08:55:32.9974784Z ok 142 - ipc_closed_handle
2020-09-20T08:55:33.1848073Z ok 143 - ipc_heavy_traffic_deadlock_bug
2020-09-20T08:55:33.2141130Z ok 144 - ipc_listen_after_write
2020-09-20T08:55:33.2437534Z ok 145 - ipc_listen_before_write
2020-09-20T08:55:33.2833107Z ok 146 - ipc_send_recv_pipe
2020-09-20T08:55:34.2991549Z ok 147 - ipc_send_recv_pipe_inprocess
2020-09-20T08:55:34.3290548Z ok 148 - ipc_send_recv_tcp
2020-09-20T08:55:35.3485703Z ok 149 - ipc_send_recv_tcp_inprocess
2020-09-20T08:55:35.3742616Z ok 150 - ipc_send_zero
2020-09-20T08:55:35.5287909Z not ok 151 - ipc_tcp_connection
2020-09-20T08:55:35.5288283Z # exit code 134
2020-09-20T08:55:35.5288588Z # Output from process `ipc_tcp_connection`:
2020-09-20T08:55:35.5288885Z # got 6 bytes
2020-09-20T08:55:35.5289075Z # 
2020-09-20T08:55:35.5289264Z # =================================================================
2020-09-20T08:55:35.5289593Z # ==6097==ERROR: LeakSanitizer: detected memory leaks
2020-09-20T08:55:35.5289894Z # 
2020-09-20T08:55:35.5290164Z # Direct leak of 248 byte(s) in 1 object(s) allocated from:
2020-09-20T08:55:35.5291109Z #     #0 0x7f0118355b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
2020-09-20T08:55:35.5292007Z #     #1 0x561ef53af2c4 in ipc_on_connection_tcp_conn /home/runner/work/libuv/libuv/test/test-ipc.c:704
2020-09-20T08:55:35.5292818Z #     #2 0x561ef547f9ca in uv__server_io /home/runner/work/libuv/libuv/src/unix/stream.c:570
2020-09-20T08:55:35.5293595Z #     #3 0x561ef54973d2 in uv__io_poll /home/runner/work/libuv/libuv/src/unix/linux-core.c:461
2020-09-20T08:55:35.5294106Z #     #4 0x561ef5454842 in uv_run /home/runner/work/libuv/libuv/src/unix/core.c:385
2020-09-20T08:55:35.5294847Z #     #5 0x561ef53b0cd2 in ipc_helper_tcp_connection /home/runner/work/libuv/libuv/test/test-ipc.c:822
2020-09-20T08:55:35.5295622Z #     #6 0x561ef533ad1e in maybe_run_test /home/runner/work/libuv/libuv/test/run-tests.c:105
2020-09-20T08:55:35.5296331Z #     #7 0x561ef533a95d in main /home/runner/work/libuv/libuv/test/run-tests.c:67
2020-09-20T08:55:35.5297027Z #     #8 0x7f0117881b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
2020-09-20T08:55:35.5297381Z # 
2020-09-20T08:55:35.5297573Z # SUMMARY: Addr
2020-09-20T08:55:35.5297910Z # essSanitizer: 248 byte(s) leaked in 1 allocation(s).
2020-09-20T08:55:35.5298223Z # exit_cb
2020-09-20T08:55:35.5298834Z # Assertion failed in /home/runner/work/libuv/libuv/test/test-ipc.c on line 105: `exit_status == 0` (1 == 0)
2020-09-20T08:55:35.5419823Z ok 152 - kill

closed time in 3 days

gengjiawen
PullRequestReviewEvent

delete branch bnoordhuis/rusty_v8

delete branch : isolate-clear_kept_objects

delete time in 3 days

push eventdenoland/rusty_v8

Ben Noordhuis

commit sha b8a2e06dc8ca2ee64067052450480c2265837483

Add Isolate::clear_kept_objects() (#507) Refs: https://github.com/denoland/deno/issues/7674

view details

push time in 3 days

PR merged denoland/rusty_v8

Add Isolate::clear_kept_objects()

Refs: https://github.com/denoland/deno/issues/7674

+52 -1

0 comment

3 changed files

bnoordhuis

pr closed time in 3 days

Pull request review commentdenoland/rusty_v8

Add Isolate::clear_kept_objects()

 fn value_serializer_not_implemented() {     "Uncaught Error: Deno serializer: get_shared_array_buffer_id not implemented"   ); }++#[test]+fn clear_kept_objects() {+  let _setup_guard = setup();++  let isolate = &mut v8::Isolate::new(Default::default());+  isolate.set_microtasks_policy(v8::MicrotasksPolicy::Explicit);++  let scope = &mut v8::HandleScope::new(isolate);+  let context = v8::Context::new(scope);+  let scope = &mut v8::ContextScope::new(scope, context);++  let step1 = r#"+    var weakrefs = [];+    for (let i = 0; i < 424242; i++) weakrefs.push(new WeakRef({ i }));

424242 might seem a little excessive but it needs to be big enough to get the GC to come online - and it completes in milliseconds on my PC.

bnoordhuis

comment created time in 3 days

PullRequestReviewEvent

PR opened denoland/rusty_v8

Add Isolate::clear_kept_objects()

Refs: https://github.com/denoland/deno/issues/7674

+52 -1

0 comment

3 changed files

pr created time in 3 days

create barnchbnoordhuis/rusty_v8

branch : isolate-clear_kept_objects

created branch time in 3 days

issue commentdenoland/deno

WeakRefs / FinalizationRegistry bugs?

Deno never calls v8::Isolate::ClearKeptObjects() - which isn't too surprising because there's no rusty_v8 binding for it. :-)

I'll open a rusty_v8 PR and see if I can find the right place in deno to slot in the call.

trgwii

comment created time in 3 days

create barnchbnoordhuis/shared_ptr-rs

branch : master

created branch time in 4 days

created repositorybnoordhuis/shared_ptr-rs

created time in 4 days

issue commentdenoland/rusty_v8

Segfaults if "use rusty_v8;" in wgpu application (OSX)

Probably won't work on Windows and older Linux machines. V8 & Chromium are fairly aggressive in adopting new C++ stdlib features.

FredrikNoren

comment created time in 5 days

issue closeddenoland/rusty_v8

[Question] Is rusty_v8::Script::compile leaking memory?

Hi,

I looked everywhere (source-code, tests, docs, api reference, even into deno-core and deno-cli repos) but I just couldn't find a way to properly dispose a Script instance after execution. At first it seemed that it woudn't be necessary to do so, as I tought it'd be automatically disposed when going out of scope, but it seems it's not the case.

Am I missing something? Any tips on how to fix it?

Minimal example:

use rusty_v8 as v8;

fn main() {
    let platform = v8::new_default_platform().unwrap();
    v8::V8::initialize_platform(platform);
    v8::V8::initialize();

    let isolate = &mut v8::Isolate::new(Default::default());

    let scope = &mut v8::HandleScope::new(isolate);
    let context = v8::Context::new(scope);
    let scope = &mut v8::ContextScope::new(scope, context);

    let code = v8::String::new(scope, "Math.min(10, 20)").unwrap();

    loop {
        {
            let script = v8::Script::compile(scope, code, None).unwrap();
        }
        // I'd expect it to have been disposed by this line, but it is not
    }
}

Caution when running the above example as in a few seconds it reached 2GB+ RAM usage on my machine.

I'd argue that by going out of scope it should be automatically disposed, as there'd be no way of referencing that particular instance to call run, or even a (future) dispose-like method.

But if you don't feel like it's a good idea to automatically dispose it, you could at least provide a way of manually doing it.

It might not be something of utmost importance for Deno itself, as it uses modules and I've only seen a few calls to this particular function (I might be wrong, though), but for embedders it's very important.

I still can't figure out how Deno's REPL implementation works without leaking memory (if I could, I'd do it the same way).

Despite my minimal example being a bit contrived, a REPL is a very real world-ish use-case that would constantly compile a new Script out of an input string, in a loop, thus leaking memory until an OOM exception finally halts the execution.

Any tips would be very appreciated. Also, I'm kinda new to Rust, so I apologize if I'm just being stupid.

Thanks!

closed time in 5 days

patrickpissurno

issue openeddenoland/rusty_v8

Shrink library size

Related issues: #465 #501

Currently all of V8 is bundled into librusty_v8.a but only the bits that rusty_v8 provides bindings to are needed.

This becomes particularly poignant when ICU is enabled because the ICU libraries are big but V8 uses only a fraction of their functionality.

GNU ld and LLVM lld support ld --gc-sections --relocatable --entry=<symbol> out.o in/*.o to strip everything that isn't reachable from <symbol>. Unfortunately, the stock ld on macOS does not. I don't know about Windows.

<sup>--gc-sections requires that C++ code is compiled with -fdata-sections -ffunction-sections but that's already the case for V8. Rust code is always compiled in that manner.</sup>

The best I can come up with right now is to mandate -C linker-flavor=ld.lld or take a dev dependency on https://lib.rs/crates/cargo-binutils.

cc @piscisaureus

created time in 5 days

issue commentdenoland/rusty_v8

Segfaults if "use rusty_v8;" in wgpu application (OSX)

I do, but I don't think that's the fix. It's not librusty_v8.a that's too promiscuous, it's librusty_v8.rlib, it re-exports the .a:

$ nm -C target/debug/librusty_v8.rlib | perl -ne 'print if /^[0-9a-f]+ T std::__1/' | head -10
0000000000000030 T std::__1::__rs_default::__rs_default(std::__1::__rs_default const&)
0000000000000000 T std::__1::__rs_default::__rs_default()
0000000000000030 T std::__1::__rs_default::__rs_default(std::__1::__rs_default const&)
0000000000000000 T std::__1::__rs_default::__rs_default()
0000000000000050 T std::__1::__rs_default::~__rs_default()
0000000000000050 T std::__1::__rs_default::~__rs_default()
00000000000000a0 T std::__1::__rs_default::operator()()
0000000000000120 T std::__1::__rs_get()
0000000000000000 T std::__1::__itoa::__u32toa(unsigned int, char*)
00000000000000b0 T std::__1::__itoa::__u64toa(unsigned long, char*)

I can think of workarounds at the linker level but rustc farms out linking to the system linker and what I have in mind works with GNU ld but not Apple ld.

FredrikNoren

comment created time in 5 days

Pull request review commentdenoland/deno

docs: Mention how to use a specific shell for Deno.run

   [stdin](https://doc.deno.land/builtin/stable#Deno.stdin),   [stdout](https://doc.deno.land/builtin/stable#Deno.stdout) and   [stderr](https://doc.deno.land/builtin/stable#Deno.stderr) streams.+- Use a specific shell by providing its path/name and it's string input switch, e.g. `Deno.run({cmd: ["bash", "-c",'"ls -la"']});
- Use a specific shell by providing its path/name and its string input switch, e.g. `Deno.run({cmd: ["bash", "-c", '"ls -la"']});

The double quotes aren't necessary with bash, that's a cmd.exe quirk.

-c is correct for bash, /d /s /c is what you want for cmd.exe.

josh-hemphill

comment created time in 7 days

PullRequestReviewEvent

issue commentdenoland/rusty_v8

Add support for ICU

@flying-sheep That's probably out of the question because V8 is only tested against a particular build of ICU - the fork that Chromium bundles - and we don't have the resources to test against other versions or builds.

Here are file sizes:

$ ls -lh lib*icu*.a | awk '{print $5 " " $9}'
19M libicuucx.a
43M libicui18n.a
27M libicudata.a

The first two contain code, where you only pay for what you use. I expect that V8 pulls in a few MB, I remember that was what it amounted to in Node.js.

The last file is the big data table ICU uses. rusty_v8 can either embed it or load it externally so it can be shared but deno probably wants to embed it.

Node.js used to ship a stripped down table containing only en_US but they (we - I was involved in that decision) stopped doing that in v14. I don't plan on revisiting that for rusty_v8 or deno.

kitsonk

comment created time in 7 days

issue commentdenoland/rusty_v8

Property Interceptors

Pull request welcome, let me know if you have questions.

PropertyCallbackInfo is already defined in src/function.rs, that should save you some work. :-)

benaubin

comment created time in 7 days

issue commentdenoland/rusty_v8

Building from source fails on macOS 11.0: "a bytes-like object is required, not 'str'"

It looks like python is python3 on your system but V8's build scripts expect python2.

kvark

comment created time in 7 days

delete branch bnoordhuis/deno

delete branch : runtime-create-params

delete time in 7 days

push eventdenoland/deno

Ben Noordhuis

commit sha 46b892ad37df9ba9bed77fb923a1cfe284b208dc

refactor(core): more control over isolate creation (#8000) Make JSRuntime::new() accept a custom v8::CreateParams object to tune the v8::Isolate it creates. Subsumes the functionality of HeapLimits, which I therefore removed.

view details

push time in 7 days

PR merged denoland/deno

refactor(core): more control over isolate creation

Make JSRuntime::new() accept a custom v8::CreateParams object to tune the v8::Isolate it creates.

Subsumes the functionality of HeapLimits, which I therefore removed.

+11 -40

1 comment

2 changed files

bnoordhuis

pr closed time in 7 days

create barnchbnoordhuis/deno

branch : runtime-create-params

created branch time in 8 days

PR opened denoland/deno

refactor(core): more control over isolate creation

Make JSRuntime::new() accept a custom v8::CreateParams object to tune the v8::Isolate it creates.

Subsumes the functionality of HeapLimits, which I therefore removed.

+11 -40

0 comment

2 changed files

pr created time in 8 days

issue commentlibuv/libuv

Is it possible to introduce wepool as libuv Windows backend?

There's some overlap with #3008 (sharing code across operating systems) but the difference of course is in the popularity of the two platforms.

VGGX

comment created time in 8 days

delete branch bnoordhuis/rusty_v8

delete branch : isolate-set_allow_atomics_wait

delete time in 8 days

push eventdenoland/rusty_v8

Ben Noordhuis

commit sha 1988c98f3c2f8a6845a9a7ac87ca73a923d631a6

Add Isolate::set_allow_atomics_wait() (#500)

view details

push time in 8 days

create barnchbnoordhuis/rusty_v8

branch : isolate-set_allow_atomics_wait

created branch time in 8 days

delete branch bnoordhuis/rusty_v8

delete branch : object-get_private

delete time in 9 days

push eventdenoland/rusty_v8

Ben Noordhuis

commit sha 1c38b66093d3e0aa8cb39a78dc91be5f85181d08

Add Object::get_private() and friends (#498)

view details

push time in 9 days

PR opened denoland/rusty_v8

Add Global::map()

Add a convenience method for unwrapping the v8::Global without a scope object. This is the same trick that Node.js applies to speed up unboxing strong persistent handles.

Refs: https://github.com/denoland/deno/issues/7969

<hr>

It's an idea I had while thinking about denoland/deno#7969. I'm not saying it's a good idea but it seems convenient to have.

+68 -0

0 comment

6 changed files

pr created time in 9 days

create barnchbnoordhuis/rusty_v8

branch : global-map

created branch time in 9 days

issue commentdenoland/deno

deno_core shouldn't use "get_identity_hash()" to identify v8 objects

I suggested implementing Hash and Eq with promise.get_identity_hash() and promise.strict_equals(other) respectively but I realize that means you need a HandleScope to unwrap the v8::Global<v8::Promise>.

Strictly speaking, you don't need one - a strong Global can be transmuted to a Local. Something like this could work:

let a: v8::Global<v8::Promise> = f();
let b: v8::Global<v8::Promise> = g();
let is_eq = a.map(|a| b.map(|b| a.strict_equals(b)));

Where .map() transmutes to Local.

Then again, maybe it's better to just assign ids and store those using private symbols. I've opened https://github.com/denoland/rusty_v8/pull/498 to flesh out v8::Private more.

bartlomieju

comment created time in 9 days

push eventbnoordhuis/rusty_v8

Ben Noordhuis

commit sha ffbdcf3c783e5b04393596673ff48871e45256d5

Add Object::get_private() and friends

view details

push time in 9 days

PR opened denoland/rusty_v8

Add Object::GetPrivate() and friends
+140 -0

0 comment

3 changed files

pr created time in 9 days

create barnchbnoordhuis/rusty_v8

branch : object-get_private

created branch time in 9 days

push eventdenoland/rusty_v8

Ben Noordhuis

commit sha 836557e84feb257a11e91d783c602a8a62e6361a

Add Module::script_id() (#497)

view details

push time in 9 days

PR merged denoland/rusty_v8

Add Module::script_id()

cc @bartlomieju

+30 -0

0 comment

3 changed files

bnoordhuis

pr closed time in 9 days

PR opened denoland/rusty_v8

Add Module::script_id()

cc @bartlomieju

+30 -0

0 comment

3 changed files

pr created time in 10 days

create barnchbnoordhuis/rusty_v8

branch : module-script_id

created branch time in 10 days

Pull request review commentdenoland/deno

fix: top-level-await module execution

 impl JsRuntime {   /// `AnyError` can be downcast to a type that exposes additional information   /// about the V8 exception. By default this type is `JsError`, however it may   /// be a different type if `RuntimeOptions::js_error_create_fn` has been set.-  pub fn mod_evaluate(&mut self, id: ModuleId) -> Result<(), AnyError> {+  pub fn dyn_mod_evaluate(+    &mut self,+    load_id: ModuleLoadId,+    id: ModuleId,+  ) -> Result<(), AnyError> {+    self.shared_init();++    let state_rc = Self::state(self.v8_isolate());+    let context = self.global_context();+    let context1 = self.global_context();++    let module_handle = state_rc+      .borrow()+      .modules+      .get_info(id)+      .expect("ModuleInfo not found")+      .handle+      .clone();++    let status = {+      let scope =+        &mut v8::HandleScope::with_context(self.v8_isolate(), context);+      let module = module_handle.get(scope);+      module.get_status()+    };++    if status == v8::ModuleStatus::Instantiated {+      // IMPORTANT: Top-level-await is enabled, which means that return value+      // of module evaluation is a promise.+      //+      // Because that promise is created internally by V8, when error occurs during+      // module evaluation the promise is rejected, and since the promise has no rejection+      // handler it will result in call to `bindings::promise_reject_callback` adding+      // the promise to pending promise rejection table - meaning JsRuntime will return+      // error on next poll().+      //+      // This situation is not desirable as we want to manually return error at the+      // end of this function to handle it further. It means we need to manually+      // remove this promise from pending promise rejection table.+      //+      // For more details see:+      // https://github.com/denoland/deno/issues/4908+      // https://v8.dev/features/top-level-await#module-execution-order+      let scope =+        &mut v8::HandleScope::with_context(self.v8_isolate(), context1);+      let module = v8::Local::new(scope, &module_handle);+      let maybe_value = module.evaluate(scope);++      // Update status after evaluating.+      let status = module.get_status();++      if let Some(value) = maybe_value {+        assert!(+          status == v8::ModuleStatus::Evaluated+            || status == v8::ModuleStatus::Errored+        );+        let promise = v8::Local::<v8::Promise>::try_from(value)+          .expect("Expected to get promise as module evaluation result");+        let promise_id = promise.get_identity_hash();

You probably need to somehow get back the id when you have a bare promise, I suppose?

It could be stored on the promise itself with a v8::Private symbol but that requires rusty_v8 to grow bindings for v8::Object::SetPrivate() and v8::Object::GetPrivate(). I can add those, I had that on my todo list anyway.

<hr>

However, that won't work for modules because they're instances of v8::Data, not v8::Object. What could work is storing them in a HashSet and implement Eq and Hash ourselves.

hash() could use module.get_identity_hash() (duplicates are okay) and eq() could compare the script id. There's currently no binding for that but it's trivial to add.

Same approach should work for promises, but using strict_equals() in eq().

bartlomieju

comment created time in 10 days

PullRequestReviewEvent

Pull request review commentdenoland/deno

fix: top-level-await module execution

 impl JsRuntime {       let poll_imports = self.poll_dyn_imports(cx)?;       assert!(poll_imports.is_ready()); +      self.evaluate_dyn_imports()?;+       self.check_promise_exceptions()?;     } -    // Ops+    // Top level module+    self.evaluate_pending_module()?;     {-      let overflow_response = self.poll_pending_ops(cx);-      self.async_op_response(overflow_response)?;-      self.drain_macrotasks()?;-      self.check_promise_exceptions()?;+      let context = self.global_context();+      let scope =+        &mut v8::HandleScope::with_context(self.v8_isolate(), context);+      scope.perform_microtask_checkpoint();

Not that it really hurts but you don't have to enter a Context here, perform_microtask_checkpoint() implicitly enters the contexts of the JS functions in the microtask queue.

(It's different if you'd use MicrotaskCallback callbacks to rust code but those should be explicit about what context they enter and rusty_v8 currently doesn't support them anyway.)

bartlomieju

comment created time in 10 days

Pull request review commentdenoland/deno

fix: top-level-await module execution

 impl JsRuntime {   /// `AnyError` can be downcast to a type that exposes additional information   /// about the V8 exception. By default this type is `JsError`, however it may   /// be a different type if `RuntimeOptions::js_error_create_fn` has been set.-  pub fn mod_evaluate(&mut self, id: ModuleId) -> Result<(), AnyError> {+  pub fn dyn_mod_evaluate(+    &mut self,+    load_id: ModuleLoadId,+    id: ModuleId,+  ) -> Result<(), AnyError> {+    self.shared_init();++    let state_rc = Self::state(self.v8_isolate());+    let context = self.global_context();+    let context1 = self.global_context();++    let module_handle = state_rc+      .borrow()+      .modules+      .get_info(id)+      .expect("ModuleInfo not found")+      .handle+      .clone();++    let status = {+      let scope =+        &mut v8::HandleScope::with_context(self.v8_isolate(), context);+      let module = module_handle.get(scope);+      module.get_status()+    };++    if status == v8::ModuleStatus::Instantiated {+      // IMPORTANT: Top-level-await is enabled, which means that return value+      // of module evaluation is a promise.+      //+      // Because that promise is created internally by V8, when error occurs during+      // module evaluation the promise is rejected, and since the promise has no rejection+      // handler it will result in call to `bindings::promise_reject_callback` adding+      // the promise to pending promise rejection table - meaning JsRuntime will return+      // error on next poll().+      //+      // This situation is not desirable as we want to manually return error at the+      // end of this function to handle it further. It means we need to manually+      // remove this promise from pending promise rejection table.+      //+      // For more details see:+      // https://github.com/denoland/deno/issues/4908+      // https://v8.dev/features/top-level-await#module-execution-order+      let scope =+        &mut v8::HandleScope::with_context(self.v8_isolate(), context1);+      let module = v8::Local::new(scope, &module_handle);+      let maybe_value = module.evaluate(scope);++      // Update status after evaluating.+      let status = module.get_status();++      if let Some(value) = maybe_value {+        assert!(+          status == v8::ModuleStatus::Evaluated+            || status == v8::ModuleStatus::Errored+        );+        let promise = v8::Local::<v8::Promise>::try_from(value)+          .expect("Expected to get promise as module evaluation result");+        let promise_id = promise.get_identity_hash();

This might be problematic. The hash is only a 22 bits random number so, per the Birthday Paradox, there's a 50% chance of a collision after ~2400 turns.

It's a bit (hah!) worse on 32 bits architectures because the hash is one bit smaller, it reaches 50% after ~1700 turns.

bartlomieju

comment created time in 10 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventbnoordhuis/v8

Ben Noordhuis

commit sha 77523bc7225fb87f6d9713f46f74b22d1823e816

[api] Add StackFrame::IsAsync() Also fix StackTrace::CurrentStackTrace() ignoring --async_stack_traces.

view details

push time in 10 days

create barnchbnoordhuis/v8

branch : stackframe-isasync

created branch time in 11 days

push eventbnoordhuis/v8

Clemens Backes

commit sha 1a911e6cbe68f4e33799af3bfa647cd9b5b6b59d

[liftoff] Materialize constants before conditional branches The number of constants stored in locals and the merge region can be arbitrarily big, thus generating arbitrarily long code for a single `br_if`. This happened in particular for unoptimized code. This CL solves this by materializing all constants (in registers or on the stack) before doing a conditional branch. This ensures that in a series of `br_if`s, each constant is only spilled once instead of on each single branch. For the linked bug, this reduces the total generated code size by ~36%. R=thibaudm@chromium.org Bug: chromium:1117033 Change-Id: I84ea2ea9ba4d3de9b042ceb223af15c3d73dc5b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364498 Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69485}

view details

Clemens Backes

commit sha 45f296f7f9a61c6f68416ad45fe0faa3d31ab414

Revert "[compiler] Remove unused holder parameter from IF_ACCESS_FROM_HEAP(_C)" This reverts commit ad68de6f5b90c0b46bd9c0b434f176e11a29f1a7. Reason for revert: Previous CL needs to be reverted (https://crrev.com/c/2364504) Original change's description: > [compiler] Remove unused holder parameter from IF_ACCESS_FROM_HEAP(_C) > > Bug: v8:7790 > Change-Id: I44849f45d1049b8a3c794dd0558b734c1e7061fd > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362919 > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69482} TBR=solanes@chromium.org,nicohartmann@chromium.org Change-Id: Iffc7a44faec8a03583aa968271a5d0e6317317a7 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364506 Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69486}

view details

Clemens Backes

commit sha 536092f779d96315994b628392b1668a6038392c

Revert "[compiler] Replace ScopeInfoData with direct reads" This reverts commit 7b9a0c20f3d2020ef594222e27ad33309fc082bb. Reason for revert: Different tests start flaking, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/29532 Original change's description: > [compiler] Replace ScopeInfoData with direct reads > > As part of this, introduce a new ObjectData kind for objects that we > want to read directly from the background thread rather than serialize. > ScopeInfoRef is the first user of that. > > For details, see: > https://docs.google.com/document/d/1U6x6Q2bpylfxS55nxSe17yyBW0bQG-ycoBhVA82VmS0/edit?usp=sharing > > Bug: v8:7790 > Change-Id: Ia3cda4f67d3922367afa4a5da2aeaae7160cf1f2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346405 > Auto-Submit: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69473} TBR=neis@chromium.org,solanes@chromium.org,nicohartmann@chromium.org Change-Id: Ide5a4a583547b63cc9accfb93fcadb97b8100e8a No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364504 Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69487}

view details

Dominik Inführ

commit sha a61393a33294efa6f4d61593e4fb9ce5922ee6e0

[heap] Make RegisterStrongRoots thread-safe CanonicalHandleScope is now also used on background threads. Therefore Heap::RegisterStrongRoots and Heap::UnregisterStrongRoots are not exclusively used on the main thread anymore. Simply protect this list with a mutex. Bug: v8:10315, v8:10814 Change-Id: Id08269c9f7fecae8c570ab711c522d111b06b005 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364503 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69488}

view details

Ng Zhi An

commit sha a85b5a63f60719a2ee737900f7e1bb4573ea7c84

[wasm-simd] Fix bounds check for load extends Load extends always load 8 bytes, so the access size does not depend on MachineType of the load. The MachineType is used for classifying the lane shape of the 8-byte load. Also add cctest to load splats and load extends to test OOB. (Note that load splats access size depends on MachineType). Add regression test from clusterfuzz, minimized by ahaas@. Remove the `--no-wasm-trap-handler` flag since we have a no_wasm_traps variant that should test this flag. Bug: chromium:1116019 Change-Id: I27ba051d0536ca0f6fd75dd641ca9b78132dafed Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2363291 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#69489}

view details

Liviu Rau

commit sha dc36a31e325e3f33bded2b66409d5dbdc670e505

Whitespace to trigger builders The plan for V8 switch to Starlark: https://docs.google.com/document/d/10zEulEuM9UWMkaU8ZMGT5Nvyg1-fJ6fnGAW5jn4wyVY/edit#heading=h.ux9y8574985 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10661 Change-Id: I56edc347ae3adc9eba306e20268745687d7c21b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364500 Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Liviu Rau <liviurau@chromium.org> Cr-Commit-Position: refs/heads/master@{#69490}

view details

Liviu Rau

commit sha cde4b2c75fce9791a8de62d6db94ccfd020ff519

Revert "Whitespace to trigger builders" This reverts commit dc36a31e325e3f33bded2b66409d5dbdc670e505. Reason for revert: to trigger builders Original change's description: > Whitespace to trigger builders > > The plan for V8 switch to Starlark: https://docs.google.com/document/d/10zEulEuM9UWMkaU8ZMGT5Nvyg1-fJ6fnGAW5jn4wyVY/edit#heading=h.ux9y8574985 > > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:10661 > Change-Id: I56edc347ae3adc9eba306e20268745687d7c21b8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364500 > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Commit-Queue: Liviu Rau <liviurau@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69490} TBR=clemensb@chromium.org,mslekova@chromium.org,liviurau@chromium.org Change-Id: I458560eaefacece3faab0c075e749417be1a814d No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10661 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2365113 Reviewed-by: Liviu Rau <liviurau@chromium.org> Commit-Queue: Liviu Rau <liviurau@chromium.org> Cr-Commit-Position: refs/heads/master@{#69491}

view details

v8-ci-autoroll-builder

commit sha 710214529bde413542a93943c3a4883f9ede4956

Update V8 DEPS. Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/78b2991..04505d9 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/5cff4e3..25f1303 NOTREECHECKS=true NOPRESUBMIT=true TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I76a41e93419494919d8ed64a300e2ee4d530c615 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364933 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#69492}

view details

v8-ci-autoroll-builder

commit sha 5f21d72a2745ba058637cbff163d8e916edd0c6a

Update V8 DEPS. Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/04505d9..183d29c Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/abfdfbb..c244e33 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/299e8a2..a4bb1c6 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Ifb0321f65a8d3e2e96bb216f24641aeb1e11d49a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2366273 Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#69493}

view details

Clemens Backes

commit sha 10a434f37eb296172011d3d09a974e92b8ec7bd8

Revert "[test] Disable asm-wasm regression test" This reverts commit f0bade979df7f10b660a90b3ed29d2288c1712f5. Reason for revert: Culprit CL reverted: https://crrev.com/c/2364504 Original change's description: > [test] Disable asm-wasm regression test > > Bug: v8:10813 > Change-Id: Ib7b3949147706552a6d569ad5fcd22f2f63d7977 > No-Try: True > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364496 > Auto-Submit: Maya Lekova <mslekova@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69479} TBR=clemensb@chromium.org,mslekova@chromium.org Change-Id: I8047db66eba1e2221654d7018c661551950f2194 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10813 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2366712 Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69494}

view details

Dominik Inführ

commit sha 41d2e5c9c0dd505910cd9edb5f9a5e8170ae8fb9

[logging] Make Log::IsEnabled() atomic With concurrent allocation background threads invoke Log::IsEnabled() as well. Fix data race here by making is_enabled_ atomic, such that IsEnabled() remains cheap. After locking the mutex in MessageBuilder, IsEnabled() needs to be checked again in case an old value was read. Otherwise we might log even though logging was already disabled on another thread. The other direction where a log message isn't logged is deemed acceptable. Bug: v8:10315 Change-Id: I32c9dd2e9879fbdb4ca94e080a16ddd875de7c30 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362948 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69495}

view details

Santiago Aboy Solanes

commit sha 5665d835a6399e858be3714359f62f35f1b7bebc

Reland "[compiler] Remove unused holder parameter from IF_ACCESS_FROM_HEAP(_C)" This is a reland of ad68de6f5b90c0b46bd9c0b434f176e11a29f1a7 Reason for reland: Reverted since another CL got reverted. This cleanup is independent though and can be relanded. Original changes description: > [compiler] Remove unused holder parameter from IF_ACCESS_FROM_HEAP(_C) > > Bug: v8:7790 > Change-Id: I44849f45d1049b8a3c794dd0558b734c1e7061fd > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362919 > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69482} Bug: v8:7790 Change-Id: Ib650ef1701168be7a910ff51e30a90e239d5f5c8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2366774 Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#69496}

view details

Victor Gomes

commit sha db15c5e3a42602eaee8e99c04efc463a0f3ac981

[builtin] Fix CallOrConstructForwardVarargs to handle reversed JS stack Change-Id: Idc204cffce49b564d134a93114a03939c3e75f20 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2307313 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#69497}

view details

Zeynep Cankara

commit sha 2afb2dcd90cb56bd7655115a5e5521b748c686c7

[tools][system-analyzer] Add stats table to timeline-tracks This CL adds a table to the right side of the each timeline-tracks to display statistics about the log events. Double clicking on an event type notifies other panels about the selected log events with the selected type. Bug: v8:10644 Change-Id: Iae523d46da4f0b6a007b02a2beac23d9c48aca02 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2353457 Commit-Queue: Zeynep Cankara <zcankara@google.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#69498}

view details

Dominik Inführ

commit sha cf929eba0f3e614d9f7e0039f3ca980197e1b41a

[heap] Make Heap::UnregisterStrongRoots work in constant time Heap::UnregisterStrongRoots needs to iterate the list of all strong roots to delete the given slot. This CL changes Heap::RegisterStrongRoots to return the pointer to the linked list node. Heap::UnregisterStrongRoots gets the node as argument and can directly delete it in constant time. The CL also introduces Heap::UpdateStrongRoots which can update a node without locking the mutex. Bug: v8:10315 Change-Id: I2c021517c010a659821f8c10de758bb49b28449f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364511 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69499}

view details

Andreas Haas

commit sha 1e6d2cb319df37c095185ede295df1f8dad089fa

[wasm][fuzzer] Enable trap handlers On x64, trap handlers are enabled as part of the default configuration. However, each embedder has to enable trap handlers explicitly, and in the wasm fuzzers, trap handlers were not enabled. This CL enables trap handlers now in all wasm fuzzers. Drive-by change: enable all staged wasm features in the wasm-async fuzzer. R=clemensb@chromium.org Change-Id: Ib7c2addb092551b5554a2b74830e5b67db077909 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362957 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69500}

view details

Jakob Gruber

commit sha faed29869fc710f169555fe3c82243e114ccafde

[nci] Change testing mode to --turbo-nci-as-midtier To properly test tier-up in the V8 test suite, change the test variant previously called --turbo-nci-as-highest-tier to --turbo-nci-as-midtier. As a midtier (between ignition and turbofan), all major parts of the NCI pipeline (codegen, caching inside the same native context, tier-up) are exercised by test suite. Bug: v8:8888 Change-Id: Ic8ee2f3e3d72768c3869f5e0b25800dd0a5f25b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2361462 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#69501}

view details

Milad Farazmand

commit sha 0589a2a209f3b975dd6a9fa7fba5ac7b64e4285e

AIX: Fix DeclareSymbolGlobal on AIX Port 929dd3748e9e29b8c858fa2e587187b84cdcfeac Original Commit Message: When CFI is enabled this adds a check against this list whenever a new return address must be set in a deoptimized frame, as a mitigation for ROP attacks. The list is known at linking time so that its content and the pointer to it can be stored in a read-only memory section. The check is performed in the signing function, which is no longer generic, as well as when setting the current pc of the frame. Since the pc is now only signed when setting the caller's pc, there is no need for ReplaceContext anymore. R=salome.thirot@arm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I5005096811c289707e2d080477c60ae2ed4bf38b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2365372 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#69502}

view details

Ulan Degenbaev

commit sha 94453a62646881f3e14384142441c9d205ebdedb

Add ulan@ to owners of src/libplatform Change-Id: I328dde4ef8265fa15e2dfc7ac689e175465edebd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2366700 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69503}

view details

Victor Gomes

commit sha 7a4148005ecd1aa1233c4f6fc19a8cea3f4bad59

[wasm] Fix access first parameter in GenericJSToWasmWrapper Adapt GenericJSToWasmWrapper to support reversed arguments stack. Change-Id: I46f6492cd8a933a7670eb2ad436a1ac84b055e60 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2366702 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#69504}

view details

push time in 11 days

delete branch bnoordhuis/rusty_v8

delete branch : isolate-set_promise_hook

delete time in 11 days

push eventdenoland/rusty_v8

Ben Noordhuis

commit sha 57390ec4ee79486361d34fdd63cecf97a4006628

Add Isolate::set_promise_hook() (#496)

view details

push time in 11 days

PR merged denoland/rusty_v8

Add Isolate::set_promise_hook()

cc @bartlomieju

+90 -0

1 comment

4 changed files

bnoordhuis

pr closed time in 11 days

Pull request review commentdenoland/rusty_v8

Add Isolate::set_promise_hook()

 fn promise_reject_callback_no_value() {   } } +#[test]+fn promise_hook() {+  extern "C" fn hook(+    type_: v8::PromiseHookType,+    promise: v8::Local<v8::Promise>,+    _parent: v8::Local<v8::Value>,+  ) {+    let scope = &mut unsafe { v8::CallbackScope::new(promise) };+    let scope = &mut v8::HandleScope::new(scope);+    let context = promise.creation_context(scope);

I added a ContextScope although it doesn't really matter here as there's only one context. But it makes sense to be theoretically correct if the test suite also doubles as ersatz documentation.

Apropos the HandleScope, I see that pattern in several other tests.

bnoordhuis

comment created time in 11 days

PullRequestReviewEvent

push eventbnoordhuis/rusty_v8

Ben Noordhuis

commit sha fb0d4499b408a353d49d0d1d7b30a7ce33beac7e

fixup! review

view details

push time in 11 days

PR opened denoland/rusty_v8

Add Isolate::set_promise_hook()

cc @bartlomieju

+90 -0

0 comment

4 changed files

pr created time in 11 days

create barnchbnoordhuis/rusty_v8

branch : isolate-set_promise_hook

created branch time in 11 days

issue commentlibuv/libuv

Extend the ability of uv_connect_cb

Your proposed API is too UNIX-centric but the general thrust is something I agree with.

There's an open (but sadly stalled) PR to reintroduce uv_import() and uv_export(): #2653

The idea behind that PR is to make it trivial to transfer handles between event loops, much easier than it is today. If that's of interest of you, maybe you can help get that PR past the finish line?

DuckVador

comment created time in 13 days

issue commentlibuv/libuv

uv__fs_copyfile is wrong for macOS

Open but somewhat stalled PR to (re-)add copyfile() support in #2578, but see #2233 for why it was removed in the first place (tl;dr it's buggy sometimes.)

greggman

comment created time in 13 days

IssuesEvent

issue commentlibuv/libuv.github.io

OpenDNS refuses DNS resolution to libuv.org

On second thought, I'll leave this open a little longer. I'd like to know if more people experience the same issue.

genio

comment created time in 13 days

issue closedlibuv/libuv.github.io

OpenDNS refuses DNS resolution to libuv.org

Since using Umbrella in the office, we're unable to access the libuv.org web site. After investigating, it claims there's an overall issue:

image

image

Would you mind double-checking things to see if DNS for libuv.org is setup correctly, please?

closed time in 13 days

genio

issue commentlibuv/libuv.github.io

OpenDNS refuses DNS resolution to libuv.org

I wouldn't know how. The support options on https://www.opendns.com/ assume you're a customer and I'm not about to create an account with them.

You're their customer, right? Can I suggest you get in touch with them? They're welcome to follow up in our issue tracker or get in touch with me over email.

I'll close this out but can reopen if necessary.

genio

comment created time in 13 days

PullRequestReviewEvent

pull request commentdenoland/deno

fix(std/test): ignore startTls test

@kitsonk I don't necessarily disagree but the test fails through no fault of the person running it. Marking it flaky seems okay to me as a stop-gap measure.

A propos a mock TLS server: that means it'd just be testing Deno.startTls() on both ends, unless it's written in e.g. python.

trivikr

comment created time in 14 days

issue commentdenoland/deno

js_unit_tests startTls fails with "Network is unreachable (os error 101)"

@trivikr The test is looking up and connecting to smtp.gmail.com:587 but that's a port some ISPs block to combat spam.

It's probably okay to mark the test as pass when it sees that error. Want to open a pull request?

trivikr

comment created time in 15 days

issue commentdenoland/deno

Deno.run options for shell control

More documentation is always good, pull request welcome.

What kind of errors do you see?

josh-hemphill

comment created time in 15 days

push eventdenoland/rusty_v8

Ben Noordhuis

commit sha ea0c7c9383db25f4e8f00442a15d601608ade56f

Fix PromiseRejectMessage::get_value() (#493) Change its return type to `Option<Local<Value>>`. The C++ API returns `Local<Value>` but that can be an empty handle. Fixes #491

view details

push time in 15 days

PR merged denoland/rusty_v8

Fix PromiseRejectMessage::get_value()

Change its return type to Option<Local<Value>>. The C++ API returns Local<Value> but that can be an empty handle.

Fixes #491

+30 -3

0 comment

2 changed files

bnoordhuis

pr closed time in 15 days

issue closeddenoland/rusty_v8

Panic while using promise reject callback

Minimum code to reproduce:

extern crate rusty_v8 as v8;

extern "C" fn p(m: v8::PromiseRejectMessage<'_>) {
    m.get_value();
}

fn main() {
    v8::V8::initialize_platform(v8::new_default_platform().unwrap());
    v8::V8::initialize();

    let mut isolate = v8::Isolate::new(Default::default());
    isolate.set_promise_reject_callback(p);

    let mut hscope = v8::HandleScope::new(&mut isolate);
    let context = v8::Context::new(&mut hscope);
    let mut cscope = v8::ContextScope::new(&mut hscope, context);

    let code = v8::String::new(&mut cscope,
        "new Promise((a,b)=>{throw new Error('test')}).then(_=>{})"
    ).unwrap();
    v8::Script::compile(
        &mut cscope, code, None
    ).unwrap().run(&mut cscope).unwrap();
}
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/lxb/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.11.0/src/promise.rs:219:8
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5
Aborted (core dumped)

If needed a backtrace can be provided via LLDB

closed time in 15 days

AlexApps99

issue commentdenoland/rusty_v8

Rust Bindings for the V8 C++ WebAssembly API

I posted a small proof of concept in #495 to validate the approach.

juliettepretot

comment created time in 15 days

PR opened denoland/rusty_v8

wee8

Proof of concept. Not ready for merge but feedback very welcome. See #490 for discussion.

The funky style is because I'm trying to transliterate v8/third-party/wasm-api/wasm.h as closely as possible in src/wee8.rs.

+129 -1

0 comment

6 changed files

pr created time in 15 days

create barnchbnoordhuis/rusty_v8

branch : wee8

created branch time in 15 days

issue commentdenoland/rusty_v8

android ndk build

I don't think there's an ETA for aarch64-linux-android support. Getting #270 merged is the first step, maybe you can help out with that?

zhuyijiang

comment created time in 15 days

issue commentdenoland/rusty_v8

Panic while using promise reject callback

Thanks for the bug report. Fix underway in #493.

AlexApps99

comment created time in 15 days

PR opened denoland/rusty_v8

Fix PromiseRejectMessage::get_value()

Change its return type to Option<Local<Value>>. The C++ API returns Local<Value> but that can be an empty handle.

Fixes #491

+30 -3

0 comment

2 changed files

pr created time in 15 days

create barnchbnoordhuis/rusty_v8

branch : fix491

created branch time in 15 days

issue commentdenoland/deno

Deno.run options for shell control

@josh-hemphill Apologies if I misunderstand your question but doesn't this work?

Deno.run({ cmd: ['cmd.exe', '/d', '/s', '/c', '"npm ls"'] }) // note the double quotes
josh-hemphill

comment created time in 15 days

issue commentdenoland/rusty_v8

Rust Bindings for the V8 C++ WebAssembly API

Practical issue: V8's libwee8.a target depends on libv8.a. I suspect you won't be able to use rusty_v8 and rusty_v8_wee8 together (because of duplicate C++ symbols during the final link) unless the latter crate depends on the former to provide libv8.a.

Not sure how easy it is to set that up. It sounds pretty hard, actually. :-)

It might be easier to compile everything into rusty_v8 and have it re-export the WASM C-API symbols:

diff --git a/BUILD.gn b/BUILD.gn
index a0624d7..1ee8f50 100644
--- a/BUILD.gn
+++ b/BUILD.gn
@@ -2,7 +2,13 @@
 
 static_library("rusty_v8") {
   complete_static_lib = true
-  sources = [ "src/binding.cc" ]
+  sources = [
+    "src/binding.cc",
+    "v8/src/wasm/c-api.cc",
+    "v8/src/wasm/c-api.h",
+    "v8/third_party/wasm-api/wasm.h",
+    "v8/third_party/wasm-api/wasm.hh",
+  ]
   deps = [
     "//build/config:shared_library_deps",
     "//v8:v8",
extern "C" {
  fn wasm_config_new() -> *mut wasm_config_t;
  fn wasm_engine_new() -> *mut wasm_engine_t;
  // etc.
}
juliettepretot

comment created time in 15 days

issue commentlibuv/libuv.github.io

OpenDNS refuses DNS resolution to libuv.org

I don't see anything obviously wrong with how libuv.org is currently configured.

It's a CNAME for libuv.github.io. (dot intentional, FQDN) and those IP addresses are indeed Github's addresses for github.io.

What may be confusing that tool you're using (although I don't see anything wrong with it) is that the SOA record for libuv.org points to ns111.auroradns.eu. admin.auroradns.eu. whereas the SOA record for github.io points to ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com..

genio

comment created time in 15 days

issue closeddenoland/rusty_v8

Build failing

Build is failing when running cargo install deno.

First I got an error with "#[track caller]" experimental feature, but I found that the beta channel for rustc was needed to compile that. Now I've switched to the beta channel, but I'm receiving a new error: image

closed time in 16 days

MariusVB

issue commentdenoland/rusty_v8

Build failing

Closing, but let me know if you're still having issues.

MariusVB

comment created time in 16 days

issue closeddenoland/rusty_v8

where is V8InspectorClient::new or how to create it

I need to use the V8 Inspector API to debug maximum call stack size reached issue in my javascript code, I saw the docs about the C++ API but I can't create V8InspectorClient object since I found no new or create or anything ?!!!

How to build that Object ?

closed time in 16 days

abnud1

issue commentdenoland/rusty_v8

where is V8InspectorClient::new or how to create it

I'll close this as answered but let me know if you have follow-up questions.

abnud1

comment created time in 16 days

issue commentdenoland/rusty_v8

Script::compile sometimes throw maximum call stack size exceeded

For reference, that was PR #272.

abnud1

comment created time in 16 days

more