Segment fault when update v8..

[YQ Tian]

v8 version 6.8.275.32

Hi all!

When I upgrade the v8 version, my program crashes. My program statically links the v8 library and also uses another dynamic library. The dynamic library will call the dynamic_cast function，  to see the crash stack of the program. The function enters the has_unambiguous_public_base function through __dynamic_cast Called, right here the program crashes. Upgrading v8, I used the monolith library instead of multiple previous libraries. Through the command `nm` I found that the updated v8 has the symbol __dynamic_cast defined. Can anyone help me understand why monolith has this symbol? What does the monolith version do? Why does my other dynamic library crash?

[YQ Tian]

And before upgrade, the v8 library don't have the __dynamic_cast symbol,

在 2020年2月28日星期五 UTC+8上午11:05:52，YQ Tian写道：

[Ben Noordhuis]

The monolithic build includes ICU and that uses dynamic_cast in
numerous places. That said, I doubt that's the reason for the crash.

Search the group for recently reported crashes. In most cases it's a
matter of ensuring both V8 and your own code are compiled with
-DV8_COMPRESS_POINTERS.

[Jakob Kummerow]

6.8 is a year and a half before pointer compression though. Which also means that 6.8 is obsolete and unsupported.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAHQurc9AJYppATmLM198dt-Q62GGUSjek1yXeFvTUcZO_n%3DM%3DQ%40mail.gmail.com.

[YQ Tian]

I changed my dynamic library to static library, and there is no problem. Is it a problem caused by symbol coverage?

在 2020年2月28日星期五 UTC+8上午11:05:52，YQ Tian写道：

v8 version 6.8.275.32

[YQ Tian]

Thank you for your reply. It is currently found that when I upgrade v8 to 6.8, the dynamic_cast function of my other dynamic library will call the has_unambiguous_public_base function in the v8 library. Normally, the C ++ standard library should be called. This phenomenon is very strange. I Compile the monolith version into multiple libraries according to the previous compilation method. Use the following command

`gn gen out.gn/x64.release --args='is_debug=false target_cpu="x64" v8_static_library=true v8_use_external_startup_data=false'`

`ninja -C out.gn/x64.release`

However, when the v8 library is introduced into the program, a link error occurs. Some symbols like c ++ abi cannot be linked. Will the upgrade you said solve this problem? Or do my compilation commands need to be modified?

在 2020年2月28日星期五 UTC+8下午7:19:51，Jakob Kummerow写道：

6.8 is a year and a half before pointer compression though. Which also means that 6.8 is obsolete and unsupported.

On Fri, Feb 28, 2020 at 12:14 PM Ben Noordhuis <in...@bnoordhuis.nl> wrote:

On Fri, Feb 28, 2020 at 4:05 AM YQ Tian <tianyuq...@gmail.com> wrote:
>
> v8 version 6.8.275.32
>
> Hi all!
>
>
> When I upgrade the v8 version, my program crashes. My program statically links the v8 library and also uses another dynamic library. The dynamic library will call the dynamic_cast function，  to see the crash stack of the program. The function enters the has_unambiguous_public_base function through __dynamic_cast Called, right here the program crashes. Upgrading v8, I used the monolith library instead of multiple previous libraries. Through the command `nm` I found that the updated v8 has the symbol __dynamic_cast defined. Can anyone help me understand why monolith has this symbol? What does the monolith version do? Why does my other dynamic library crash?

The monolithic build includes ICU and that uses dynamic_cast in
numerous places. That said, I doubt that's the reason for the crash.

Search the group for recently reported crashes. In most cases it's a
matter of ensuring both V8 and your own code are compiled with
-DV8_COMPRESS_POINTERS.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to v8-u...@googlegroups.com.

[YQ Tian]

Thank you for your reply. It is currently found that when I upgrade v8 to 6.8, the dynamic_cast function of my other dynamic library will call the has_unambiguous_public_base function in the v8 library. Normally, the C ++ standard library should be called. This phenomenon is very strange. I Compile the monolith version into multiple libraries according to the previous compilation method. Use the following command

`gn gen out.gn/x64.release --args='is_debug=false target_cpu="x64" v8_static_library=true v8_use_external_startup_data=false'`

`ninja -C out.gn/x64.release`

However, when the v8 library is introduced into the program, a link error occurs. Some symbols like c ++ abi cannot be linked.  do my compilation commands need to be modified?

在 2020年2月28日星期五 UTC+8下午7:14:25，Ben Noordhuis写道：

[Ben Noordhuis]

On Sat, Feb 29, 2020 at 5:26 AM YQ Tian <tianyuq...@gmail.com> wrote:>
> Thank you for your reply. It is currently found that when I upgrade v8 to 6.8, the dynamic_cast function of my other dynamic library will call the has_unambiguous_public_base function in the v8 library. Normally, the C ++ standard library should be called. This phenomenon is very strange. I Compile the monolith version into multiple libraries according to the previous compilation method. Use the following command
>
> `gn gen out.gn/x64.release --args='is_debug=false target_cpu="x64" v8_static_library=true v8_use_external_startup_data=false'`
>
> `ninja -C out.gn/x64.release`
>
> However, when the v8 library is introduced into the program, a link error occurs. Some symbols like c ++ abi cannot be linked. Will the upgrade you said solve this problem? Or do my compilation commands need to be modified?

V8 links to its own copy of libc++ unless told otherwise. I believe
it's the use_custom_libcxx=false option.

[YQ Tian]

Thank you very much, the option use_custom_libcxx=false  can indeed use the c ++ standard library instead of the internal c ++ library of v8, but when compiling,  torque requires a higher version of glibc. Due to program reasons, I cannot link the higher version of the c ++ library. Can I compile v8 without using a higher version of the C ++ library？

在 2020年2月29日星期六 UTC+8下午5:00:14，Ben Noordhuis写道：