LInux: no line numbers on stacktraces from DCHECKs

[David Grogan]

I don't see line numbers in stack traces on Linux and I can't figure out why. What should I check? Are the libc_interceptor error messages related?

args.gn:

is_component_build = true

use_goma = true

is_debug = false

dcheck_always_on = true

Here's a stack trace I got with some libc error messages near the top:

[62218:62218:0103/171530.263510:INFO:content_main_runner_impl.cc(966)] Chrome is running in full browser mode.

DevTools listening on ws://127.0.0.1:46493/devtools/browser/49963d0b-3bc5-4507-887a-5905048f84b9

[62243:1:0103/171530.360373:ERROR:libc_interceptor.cc(199)] Your system is broken: dlsym doesn't work! This has been reported to be caused by Nvidia's libGL. You should expect time related functions to misbehave. https://bugs.chromium.org/p/chromium/issues/detail?id=16800

[62244:1:0103/171530.361710:ERROR:libc_interceptor.cc(199)] Your system is broken: dlsym doesn't work! This has been reported to be caused by Nvidia's libGL. You should expect time related functions to misbehave. https://bugs.chromium.org/p/chromium/issues/detail?id=16800

[62239:62239:0103/171530.471169:ERROR:libc_interceptor.cc(199)] Your system is broken: dlsym doesn't work! This has been reported to be caused by Nvidia's libGL. You should expect time related functions to misbehave. https://bugs.chromium.org/p/chromium/issues/detail?id=16800

[62237:62237:0103/171530.847832:ERROR:libc_interceptor.cc(199)] Your system is broken: dlsym doesn't work! This has been reported to be caused by Nvidia's libGL. You should expect time related functions to misbehave. https://bugs.chromium.org/p/chromium/issues/detail?id=16800

[62244:1:0103/171530.983979:FATAL:ng_flex_layout_algorithm.cc(699)] Check failed: false. 

#0 0x7f10e7c1a8f9 base::debug::CollectStackTrace()

#1 0x7f10e7af48a3 base::debug::StackTrace::StackTrace()

#2 0x7f10e7b16f34 logging::LogMessage::~LogMessage()

#3 0x7f10e263d2eb blink::NGFlexLayoutAlgorithm::Layout()

#4 0x7f10e2628caa _ZN5blink12_GLOBAL__N_121CreateAlgorithmAndRunINS_21NGFlexLayoutAlgorithmEZNS0_19LayoutWithAlgorithmERKNS_23NGLayoutAlgorithmParamsEEUlPNS_27NGLayoutAlgorithmOperationsEE_EEvS5_RKT0_

#5 0x7f10e2628af6 _ZN5blink12_GLOBAL__N_124DetermineAlgorithmAndRunIZNS0_19LayoutWithAlgorithmERKNS_23NGLayoutAlgorithmParamsEEUlPNS_27NGLayoutAlgorithmOperationsEE_EEvS4_RKT_

#6 0x7f10e2620e0c blink::NGBlockNode::Layout()

#7 0x7f10e262528f blink::NGBlockNode::ComputeMinMaxSize()

#8 0x7f10e264284d blink::NGLayoutInputNode::ComputeMinMaxSize()

#9 0x7f10e264a89e blink::ComputeMinAndMaxContentContribution()

[snip]

[Daniel Bratell]

The gn argument is_debug = false will reduce the amount of debugging information available. You can try setting symbol_level to 1 (should be enough I hope) or 2 (probably overkill), but I'm not sure it will work.

/Daniel

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/855ad59a-36c1-4a59-aead-e45900e350b5%40chromium.org.

[Bruce Dawson]

There are ongoing discussions about what the various symbol_level settings should mean as we try to balance build performance, build size, and stackwalk performance, all across multiple platforms. See crbug.com/985255 for some recent discussions about Windows to give you a sense of it.

Historically on Linux symbol_level=1 has given function names, file names, and line numbers. This proved too expensive in some cases so some bots were recentishly changed to symbol_level=0 which on Linux (I believe) gives just function names.

Meanwhile on Windows symbol_level=1 has historically given just function names. That was recentishly changed to include file names and line numbers. This proved too expensive on some bots (Windows 7 stack walks started timing out) so now we're deciding whether to change the meaning of symbol_level=1 back, change the meaning of symbol_level=0 and switch some bots to use it, or let the problematic bots opt-out of file names and line numbers. See crrev.com/c/1796862 and crrev.com/c/1986973 for possible changes to start resolving this.

In addition to the slightly different meanings of symbol_level=0/1/2 the different platforms have different default values for symbol_level. On Windows the default is symbol_level=2 and on Linux (unless using sanitizer) the default is symbol_level=0.

So the short answer is that you aren't getting filenames/line-numbers because you didn't ask for them. Set symbol_level=1, or set it to 2 if you want full debugging. See compiler.gni for the full logic.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[dan...@chromium.org]

Do other linux devs get line numbers with symbol_level=2? I certainly don't and I've just become resigned to this.

args.gn:

use_goma = true
enable_nacl = false

is_debug = false
dcheck_always_on = true

is_component_build = true
symbol_level = 2

Example NOTREACHED():

[255943:255943:0106/144706.712819:269437935989:FATAL:callback_unittest.cc(235)] Check failed: false.
#0 0x7f496794f8f9 base::debug::CollectStackTrace()
#1 0x7f49678298a3 base::debug::StackTrace::StackTrace()
#2 0x7f496784bf34 logging::LogMessage::~LogMessage()
#3 0x55acb4742bdf base::(anonymous namespace)::CallbackTest_CallbackHasLastRefOnContainingObject_Test::TestBody()
#4 0x55acb53fa2d1 testing::Test::Run()
#5 0x55acb53fb22f testing::TestInfo::Run()
#6 0x55acb53fb9d7 testing::TestSuite::Run()
#7 0x55acb540bca7 testing::internal::UnitTestImpl::RunAllTests()
#8 0x55acb540b762 testing::UnitTest::Run()
#9 0x55acb54263d2 base::TestSuite::Run()
#10 0x55acb544b6f0 base::(anonymous namespace)::LaunchUnitTestsInternal()
#11 0x55acb544b539 base::LaunchUnitTests()
#12 0x55acb5412daf main
#13 0x7f496660452b __libc_start_main
#14 0x55acb46db1fa _start

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/855ad59a-36c1-4a59-aead-e45900e350b5%40chromium.org.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/a7df35a7-ede2-4155-901a-229a67a3442d%40chromium.org.

[Daniel Cheng]

Your output looks a bit surprising to me: it looks like some symbols aren't unmangled? Not sure why that's happening...

There's also https://bugs.chromium.org/p/chromium/issues/detail?id=1039359 filed today about the line number difference between Linux and non-Linux bots.

FWIW, I've often found that it's most reliable to have a sanitizer build and then just pipe the output through tools/valgrind/asan/third_party/asan_symbolize.py.

Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHtyhaT3aS4a_O5P5-sysTTGTwDx82FFHjGkXfppp%2BPRHBboGQ%40mail.gmail.com.

[dan...@chromium.org]

On Mon, Jan 6, 2020 at 3:11 PM Daniel Cheng <dch...@chromium.org> wrote:

Your output looks a bit surprising to me: it looks like some symbols aren't unmangled? Not sure why that's happening...

I don't think anything is mangled, that is just gtest macro magic making weird names for test bodies I think.

[Michael Spang]

On Mon, Jan 6, 2020 at 3:12 PM Daniel Cheng <dch...@chromium.org> wrote:
>
> Your output looks a bit surprising to me: it looks like some symbols aren't unmangled? Not sure why that's happening...
>
> There's also https://bugs.chromium.org/p/chromium/issues/detail?id=1039359 filed today about the line number difference between Linux and non-Linux bots.
>
> FWIW, I've often found that it's most reliable to have a sanitizer build and then just pipe the output through tools/valgrind/asan/third_party/asan_symbolize.py.

You can set

print_unsymbolized_stack_traces=true

to be able to use asan_symbolize.py without a sanitizer build. This
gives nicer output than the internal symbolization and also produces
usable output even with a stripped binary.

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAF3XrKrEa7Fq7cFA1bv-mAN8xwRfj%2BiR0k7jxhY9nyybywB0Ag%40mail.gmail.com.

[Michael Spang]

On Mon, Jan 6, 2020 at 3:16 PM <dan...@chromium.org> wrote:
>
> On Mon, Jan 6, 2020 at 3:11 PM Daniel Cheng <dch...@chromium.org> wrote:
>>
>> Your output looks a bit surprising to me: it looks like some symbols aren't unmangled? Not sure why that's happening...
>
>
> I don't think anything is mangled, that is just gtest macro magic making weird names for test bodies I think.

They are mangled, but the internal demangler isn't very good.

Pipe the output through c++filt or use asan_symbolize.

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHtyhaQynBHO6baAftyGg61vtS9KsYZ%3DL%2BdP8DhWu3rj6UrRug%40mail.gmail.com.

[Michael Spang]

Oh, sorry, you had a different trace. I think Daniel was talking about
the original one, particularly these names:

#4 0x7f10e2628caa
_ZN5blink12_GLOBAL__N_121CreateAlgorithmAndRunINS_21NGFlexLayoutAlgorithmEZNS0_19LayoutWithAlgorithmERKNS_23NGLayoutAlgorithmParamsEEUlPNS_27NGLayoutAlgorithmOperationsEE_EEvS5_RKT0_
#5 0x7f10e2628af6
_ZN5blink12_GLOBAL__N_124DetermineAlgorithmAndRunIZNS0_19LayoutWithAlgorithmERKNS_23NGLayoutAlgorithmParamsEEUlPNS_27NGLayoutAlgorithmOperationsEE_EEvS4_RKT_

[David Grogan]

On Mon, Jan 6, 2020 at 11:41 AM Bruce Dawson <bruce...@chromium.org> wrote:

So the short answer is that you aren't getting filenames/line-numbers because you didn't ask for them. Set symbol_level=1, or set it to 2 if you want full debugging. See compiler.gni for the full logic.

Thanks for the background. symbol_level=2 and blink_symbol_level=2 don't seem to do the trick for me though, I still get no line numbers :(

args.gn

enable_nacl = false
enable_pdf = true
enable_print_preview = false

is_component_build = true
use_goma = true

symbol_level = 2
blink_symbol_level = 2

is_debug = false
dcheck_always_on = true

output

#0 0x7f33350228f9 base::debug::CollectStackTrace()
#1 0x7f3334efc8a3 base::debug::StackTrace::StackTrace()
#2 0x7f33350223b1 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#3 0x7f33296e43a0 <unknown>
#4 0x7f3328fc9cfb gsignal
#5 0x7f3328fb48ad abort
#6 0x7f3335021005 base::debug::BreakDebugger()
#7 0x7f3334f1f47a logging::LogMessage::~LogMessage()
#8 0x7f332fa452eb blink::NGFlexLayoutAlgorithm::Layout()
#9 0x7f332fa30caa _ZN5blink12_GLOBAL__N_121CreateAlgorithmAndRunINS_21NGFlexLayoutAlgorithmEZNS0_19LayoutWithAlgorithmERKNS_23NGLayoutAlgorithmParamsEEUlPNS_27NGLayoutAlgorithmOperationsEE_EEvS5_RKT0_
#10 0x7f332fa30af6 _ZN5blink12_GLOBAL__N_124DetermineAlgorithmAndRunIZNS0_19LayoutWithAlgorithmERKNS_23NGLayoutAlgorithmParamsEEUlPNS_27NGLayoutAlgorithmOperationsEE_EEvS4_RKT_
#11 0x7f332fa28e0c blink::NGBlockNode::Layout()
#12 0x7f332fa2d28f blink::NGBlockNode::ComputeMinMaxSize()
#13 0x7f332fa4a84d blink::NGLayoutInputNode::ComputeMinMaxSize()

 

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Bruce Dawson]

Step one is making sure the debug information has filenames/line numbers. You've done that, and when debugging Chrome with gdb you should get source/line information (and types).

Apparently step two is getting our stack dumper on Linux to use that information. I am but a simple Windows developer so I have no theories on this, but it sounds like you are not alone.

[Michael Spang]

It is expected that internal stack traces (base::debug::StackTrace,
CHECK(0), LOG(FATAL)) don't show line numbers. The internal symbolizer
isn't that advanced (and since it runs in signal handlers, it's
awkward to extend).

You need to either attach a debugger, or use asan_symbolize.py. For example:

gn gen out/linux_rel --args='is_debug=false use_goma=true
symbol_level=1 is_component_build=true dcheck_always_on=true'
ninja -C out/linux_rel -j1000 -k50 -l32 chrome
cd ./out/linux_rel
./out/linux_rel/chrome chrome://crash |&
./tools/valgrind/asan/asan_symbolize.py

[78806:78806:0106/162825.592210:FATAL:personal_data_manager.cc(2534)]
Check failed: !primary_account_id.IsEmail().
#0 0x7f306a756e59 in base::debug::CollectStackTrace(void**,
unsigned long) ./../../base/debug/stack_trace_posix.cc:840:39
#1 0x7f306a630ee3 in StackTrace ./../../base/debug/stack_trace.cc:206:12
#2 0x7f306a630ee3 in base::debug::StackTrace::StackTrace()
./../../base/debug/stack_trace.cc:203:28
#3 0x7f306a653574 in logging::LogMessage::~LogMessage()
./../../base/logging.cc:628:29
#4 0x56213a53f913 in
autofill::PersonalDataManager::MigrateUserOptedInWalletSyncTransportIfNeeded()
./../../components/autofill/core/browser/personal_data_manager.cc:2534:3
#5 0x562139cc5e20 in
ProfileSyncServiceFactory::BuildServiceInstanceFor(content::BrowserContext*)
const ./../../chrome/browser/sync/profile_sync_service_factory.cc:302:8
#6 0x7f3063cfaa25 in
BrowserContextKeyedServiceFactory::BuildServiceInstanceFor(void*)
const ./../../components/keyed_service/content/browser_context_keyed_service_factory.cc:98:7
#7 0x7f306625af36 in
KeyedServiceFactory::GetServiceForContext(void*, bool)
./../../components/keyed_service/core/keyed_service_factory.cc:77:15
#8 0x562139c86aba in
SharingServiceFactory::BuildServiceInstanceFor(content::BrowserContext*)
const ./../../chrome/browser/sharing/sharing_service_factory.cc:84:7
#9 0x7f3063cfaa25 in
BrowserContextKeyedServiceFactory::BuildServiceInstanceFor(void*)
const ./../../components/keyed_service/content/browser_context_keyed_service_factory.cc:98:7
#10 0x7f306625af36 in
KeyedServiceFactory::GetServiceForContext(void*, bool)
./../../components/keyed_service/core/keyed_service_factory.cc:77:15
#11 0x562139c392b9 in ProfileImpl::DoFinalInit()
./../../chrome/browser/profiles/profile_impl.cc:727:3
#12 0x562139c3af2b in ProfileImpl::OnLocaleReady()
./../../chrome/browser/profiles/profile_impl.cc:965:3
#13 0x562139c38707 in
ProfileImpl::OnPrefsLoaded(Profile::CreateMode, bool)
./../../chrome/browser/profiles/profile_impl.cc:995:3
#14 0x562139c38033 in ProfileImpl::ProfileImpl(base::FilePath
const&, Profile::Delegate*, Profile::CreateMode, base::Time,
scoped_refptr<base::SequencedTaskRunner>)
./../../chrome/browser/profiles/profile_impl.cc:517:5
#15 0x562139c3665e in Profile::CreateProfile(base::FilePath
const&, Profile::Delegate*, Profile::CreateMode)
./../../chrome/browser/profiles/profile_impl.cc:355:59
#16 0x562139c60066 in
ProfileManager::CreateProfileHelper(base::FilePath const&)
./../../chrome/browser/profiles/profile_manager.cc:1170:10
#17 0x562139c5942c in
ProfileManager::CreateAndInitializeProfile(base::FilePath const&)
./../../chrome/browser/profiles/profile_manager.cc:1408:38
#18 0x562139c591f5 in ProfileManager::GetProfile(base::FilePath
const&) ./../../chrome/browser/profiles/profile_manager.cc:506:10
#19 0x56213afb3c40 in GetStartupProfile(base::FilePath const&,
base::CommandLine const&)
./../../chrome/browser/ui/startup/startup_browser_creator.cc:1045:39
#20 0x562139a14708 in CreatePrimaryProfile
./../../chrome/browser/chrome_browser_main.cc:437:13
#21 0x562139a14708 in
ChromeBrowserMainParts::PreMainMessageLoopRunImpl()
./../../chrome/browser/chrome_browser_main.cc:1532:14
#22 0x562139a13cb9 in
ChromeBrowserMainParts::PreMainMessageLoopRun()
./../../chrome/browser/chrome_browser_main.cc:1199:18
#23 0x7f30678b8957 in
content::BrowserMainLoop::PreMainMessageLoopRun()
./../../content/browser/browser_main_loop.cc:1028:13
#24 0x7f3067ede68b in Run ./../../base/callback.h:98:12
#25 0x7f3067ede68b in content::StartupTaskRunner::RunAllTasksNow()
./../../content/browser/startup_task_runner.cc:41:29
#26 0x7f30678b796e in
content::BrowserMainLoop::CreateStartupTasks()
./../../content/browser/browser_main_loop.cc:937:25
#27 0x7f30678bab9a in
content::BrowserMainRunnerImpl::Initialize(content::MainFunctionParams
const&) ./../../content/browser/browser_main_runner_impl.cc:129:15
#28 0x7f30678b579d in
content::BrowserMain(content::MainFunctionParams const&)
./../../content/browser/browser_main.cc:43:32
#29 0x7f30684221d7 in RunBrowserProcessMain
./../../content/app/content_main_runner_impl.cc:536:10
#30 0x7f30684221d7 in
content::ContentMainRunnerImpl::RunServiceManager(content::MainFunctionParams&,
bool) ./../../content/app/content_main_runner_impl.cc:969:10
#31 0x7f3068421db6 in content::ContentMainRunnerImpl::Run(bool)
./../../content/app/content_main_runner_impl.cc:877:12
#32 0x7f30589cdd0d in
service_manager::Main(service_manager::MainParams const&)
./../../services/service_manager/embedder/main.cc:423:29
#33 0x7f306841fac1 in
content::ContentMain(content::ContentMainParams const&)
./../../content/app/content_main.cc:19:10
#34 0x56213915702d in ChromeMain ./../../chrome/app/chrome_main.cc:121:12
#35 0x7f305a6b152b in __libc_start_main ??:0:0
#36 0x562139156d5a in _start ??:0:0

Michael

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAE5mQiMzZqG_g8D72x_aY2wxACejUrKtgJBt0uzA7FupK271bQ%40mail.gmail.com.

[Michael Spang]

On Mon, Jan 6, 2020 at 4:28 PM Michael Spang <sp...@chromium.org> wrote:
>
> It is expected that internal stack traces (base::debug::StackTrace,
> CHECK(0), LOG(FATAL)) don't show line numbers. The internal symbolizer
> isn't that advanced (and since it runs in signal handlers, it's
> awkward to extend).
>
> You need to either attach a debugger, or use asan_symbolize.py. For example:
>
> gn gen out/linux_rel --args='is_debug=false use_goma=true
> symbol_level=1 is_component_build=true dcheck_always_on=true'

Oops, missed the key argument:

gn gen out/linux_rel --args='is_debug=false use_goma=true

symbol_level=1 dcheck_always_on=true is_component_build=true
print_unsymbolized_stack_traces=true'

[James Darpinian]

+1 for print_unsymbolized_stack_traces=true and |& tools/valgrind/asan/asan_symbolize.py. The full file paths you get this way are also useful for editor integration.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAC5F_1kXDaCVU0iMeG3b3x2mt2jA8Vykv%3D6S3wqg%2ByY8bQjYRw%40mail.gmail.com.

[Michael Spang]

Nice, hadn't considered that. There's at least 3 advantages to doing this:

- better output after post-processing the trace (full object paths,
line numbers, more robust demangling)
- works with stripped binaries
- editor integration

I wonder if we should change the default. Although the current format
is more immediately readable, it's actually losing valuable
information.





Michael

[Fergal Daly]

On Tuesday, January 7, 2020 at 10:29:41 AM UTC+9, Michael Spang wrote:

Nice, hadn't considered that. There's at least 3 advantages to doing this:

- better output after post-processing the trace (full object paths,
line numbers, more robust demangling)
- works with stripped binaries
- editor integration

I wonder if we should change the default. Although the current format
is more immediately readable, it's actually losing valuable
information.

Did anything happen here? The current situation is choosing between

- manually symbolizing every time but you can get line numbers if you need them

- auto symbolizing but no possibility of line numbers

What would it take to get auto symbolizing that can be used by asan_symbolize? Do we just need to dump out the memory map too?

F

 

>> > >>>> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

>> > >>>> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/855ad59a-36c1-4a59-aead-e45900e350b5%40chromium.org.
>> > >
>> > > --
>> > > --
>> > > Chromium Developers mailing list: chromi...@chromium.org
>> > > View archives, change email options, or unsubscribe:
>> > > http://groups.google.com/a/chromium.org/group/chromium-dev
>> > > ---
>> > > You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

>> > > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

>> > > To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAE5mQiMzZqG_g8D72x_aY2wxACejUrKtgJBt0uzA7FupK271bQ%40mail.gmail.com.
>>
>> --
>> --
>> Chromium Developers mailing list: chromi...@chromium.org
>> View archives, change email options, or unsubscribe:
>>     http://groups.google.com/a/chromium.org/group/chromium-dev
>> ---
>> You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[Daniel Cheng]

Many years later, as of crrev.com/c/5342425, stack traces should include line numbers on Linux now by default. Thanks to ajwong@ for the original implementation and those who've contributed fixes!

The only requirement is that you build with symbol_level > 0. Sadly, I believe most of the bots build with symbol_level = 0, but this should help with local debugging at least.

Daniel

P.S. if anyone wants to figure out how to make this work with DWARF5, that might come in useful at some point :)

>> > >>>> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

>> > >>>> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/855ad59a-36c1-4a59-aead-e45900e350b5%40chromium.org.
>> > >
>> > > --
>> > > --
>> > > Chromium Developers mailing list: chromi...@chromium.org
>> > > View archives, change email options, or unsubscribe:
>> > > http://groups.google.com/a/chromium.org/group/chromium-dev
>> > > ---
>> > > You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

>> > > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

>> > > To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAE5mQiMzZqG_g8D72x_aY2wxACejUrKtgJBt0uzA7FupK271bQ%40mail.gmail.com.
>>
>> --
>> --
>> Chromium Developers mailing list: chromi...@chromium.org
>> View archives, change email options, or unsubscribe:
>>     http://groups.google.com/a/chromium.org/group/chromium-dev
>> ---
>> You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

>> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAC5F_1kXDaCVU0iMeG3b3x2mt2jA8Vykv%3D6S3wqg%2ByY8bQjYRw%40mail.gmail.com.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/2a3eef47-9737-4f71-b683-350026b0c9e8%40chromium.org.

[Fergal Daly]

On Fri, 8 Mar 2024 at 04:10, Daniel Cheng <dch...@chromium.org> wrote:

Many years later, as of crrev.com/c/5342425, stack traces should include line numbers on Linux now by default. Thanks to ajwong@ for the original implementation and those who've contributed fixes!

The only requirement is that you build with symbol_level > 0. Sadly, I believe most of the bots build with symbol_level = 0, but this should help with local debugging at least.

Great news. Thanks!

F