The base::debug::StackTrace can NOT print the Backtrace of function call sequence neither by the interface PrintBacktrace() or OutputToStream() with Cobalt QA version, so is there a way to print the backtrace with Cobalt QA version?
In src/base/debug/stack_trace_starboard.cc, StackTrace::PrintBacktrace() passes the stack into a PrintBacktraceOutputHandler, which ultimately outputs to SbLogRaw(), which in src/starboard/shared/posix/log_raw.cc should write() to STDERR_FILENO, regardless of build type.
When I try this in linux-x64x11_qa Cobalt:
base::debug::StackTrace().PrintBacktrace();
LOG(INFO) << base::debug::StackTrace().ToString();
I get two stack traces printed:
SbEventHandle [0x4158e4]
starboard::shared::starboard::Application::DispatchStart() [0x4933b8]
starboard::shared::starboard::Application::Run() [0x49330e]
main [0x48c248]
<unknown> [0x7f272613cf45]
<unknown> [0x4156b9]
<unknown> [0x4156b9]
[0113/132642:INFO:main.cc(37)] SbEventHandle [0x415950]
starboard::shared::starboard::Application::DispatchStart() [0x4933b8]
starboard::shared::starboard::Application::Run() [0x49330e]
main [0x48c248]
<unknown> [0x7f272613cf45]
<unknown> [0x4156b9]
<unknown> [0x4156b9]
Since this ultimately writes out to SbLogRaw(), I'd look at how that is behaving in QA builds to see what your problem is.
Related
Prior to upgrading, everything ran perfectly fine. This is the full error I have received post upgrade:
type 'DillSetterBuilder' is not a subtype of type 'SourceMemberBuilderImpl?' in type cast
#0 SourceLibraryBuilder.checkMemberConflicts.<anonymous closure> (package:front_end/src/fasta/source/source_library_builder.dart:998:22)
#1 _LinkedHashMapMixin.forEach (dart:collection-patch/compact_hash.dart:574:13)
#2 Scope.forEachLocalSetter (package:front_end/src/fasta/scope.dart:424:14)
#3 SourceLibraryBuilder.checkMemberConflicts (package:front_end/src/fasta/source/source_library_builder.dart:974:11)
#4 SourceLibraryBuilder.build (package:front_end/src/fasta/source/source_library_builder.dart:1057:5)
#5 IncrementalCompiler.compileExpression.<anonymous closure> (package:front_end/src/fasta/incremental_compiler.dart:1817:20)
#6 IncrementalCompiler.compileExpression.<anonymous closure>
[#7-#59...]
the Dart compiler exited unexpectedly.
the Dart compiler exited unexpectedly.
According to https://github.com/flutter/flutter/issues/97500#issuecomment-1044083031 this is fixed in the master branch, which means you will need to wait until the fix reaches the beta branch and is released to the beta channel. Alternatively you can revert to the stable channel.
I switched to the stable flutter channel by typing flutter channel stable in the terminal and that worked for me!
If the following command is run in cmd, the problem will be solved.
dart --enable-analytics
I think the program is trying to read data from the server, but the server is not working, so it makes an error. Check that the API is working.
I'm new to NS3. I studied vanet-routing-compair.cc script. I tried to run it by these commands (vanet-routing-compare.cc is in scratch folder).
./waf --run scratch/vanet-routing-compare
./waf --run "vanet-routing-compare --scenario=1 --saveconfig=scenario1.txt"
But I'm getting confused with the results. I get following error messages.
msg="Could not connect callback to /NodeList/*/DeviceList/*/ns3::WifiNetDevice/Phy/PhyTxDrop", file=../src/core/model/config.cc, line=920 terminate called without an active exception
Command ['/home/azra/Desktop/ns-allinone-3.31/ns-3.31/build/scratch/vanet-routing-compare'] terminated with signal SIGIOT. Run it under a debugger to get more information (./waf --run <program> --gdb").
And by using the gdb debugger, I see this message.
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/azra/Desktop/ns-allinone-3.31/ns-3.31/build/scratch/vanet-routing- compare --scenario=1 --saveconfig=scenario1.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
msg="Could not connect callback to /NodeList/*/DeviceList/*/ns3::WifiNetDevice /Phy/PhyTxDrop", file=../src/core/model/config.cc, line=920
terminate called without an active exception
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 }
I appreciate who can help me understand why this is happening and how I can solve it.
I got the same error in version 3.31, but the version 3.30 is ok. Maybe you can also try version 3.30.
I believe since version 3.31 the names changed from ns3:: to $ns3::
https://groups.google.com/g/ns-3-users/c/VWTV9ZdY7fs/m/MxRdIoLoAAAJ[Here][1]
The workaround I use is to copy the entire file from here:gitlab of ns3 development branch
As you can see, there were few (more than a few) changes in the code.
I am creating a new Platform/Device for Tensorflow.
I have registered my Platform and right now am developing an Operation.
As it happens in development i am getting a crash and am trying to debug it with gdb.
The issue is that although i have added flags in bazel to generate the debug version of tensorflow, gdb does not show file/line numbers in the backtrace, nor can i see variables and code:
#0 0x00007fffe288d7f4 in tensorflow::Tensor::DebugString(int) const () from /tmp/TensorflowVT/vt_tf/lib/python3.4/site-packages/tensorflow/python/../libtensorflow_framework.so
#1 0x00007fffe4cd1373 in ConstOp::Compute(tensorflow::OpKernelContext*) () from /tmp/TensorflowVT/vt_tf/lib/python3.4/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#2 0x00007fffe2a9ab4d in tensorflow::(anonymous namespace)::ExecutorState::Process(tensorflow::(anonymous namespace)::ExecutorState::TaggedNode, long long) () from /tmp/TensorflowVT/vt_tf/lib/python3.4/site-packages/tensorflow/python/../libtensorflow_framework.so
I am building tensorflow like this:
bazel build --incompatible_remove_native_http_archive=false --incompatible_package_name_is_a_function=false --config=opt --verbose_failures --compilation_mode=dbg -c dbg --strip=never //tensorflow/tools/pip_package:build_pip_package
I also tried manualy finding the crash point, and added debug prints in
tensorflow/core/framework/tensor.cc, but
Is it possible to get file/lines and annotated code, to better understand where and why i get the crash?
Apache on a production server of mine is seg faulting intermittently. I have enabled core dump option in apache configuration and have several dumped core files. Unfortunately, since it is a production server, apache or the loaded modules are not compiled with debug symbols. From what I understand, gdb cannot do much without debug symbols.
Can I at least find out which module is causing the seg fault, without debug symbols? If so, how?
[Update]
Following is the output from a gdb backtrace
(gdb) bt full
#0 0xb7f1f832 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
No symbol table info available.
#1 0xb7be82bc in pthread_cond_wait##GLIBC_2.3.2 () from /lib/libpthread.so.0
No symbol table info available.
#2 0xb771652a in ?? () from /usr/local/apache/modules/mod_pagespeed.so
No symbol table info available.
#3 0xb75df576 in ?? () from /usr/local/apache/modules/mod_pagespeed.so
No symbol table info available.
#4 0xb7715c20 in ?? () from /usr/local/apache/modules/mod_pagespeed.so
No symbol table info available.
#5 0xb7be4a49 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6 0xb7b2a63e in clone () from /lib/libc.so.6
No symbol table info available.
Does this mean that /lib/ld-linux.so.2 is causing the seg fault?
A quick search for _dl_sysinfo_int80 revealed the following thread ...
http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.apps/2005-02/0462.html
To answer you question I doubt that /lib/ld-linux.so.2 is causing the segmentation fault. This is just one of many threads that is waiting.
Run thread apply all bt full to get stack traces of all the threads running at the time of the crash. It should be then be clear which thread is causing the SEGFAULT. This should provide you with more evidence of what is going on.
Ubuntu 12.04, Mono 2.10.8.1-5
I have built the "hello world" console app that MonoDevelop creates as a default. It runs as expected. When I add the trace option (directed into a file, or not), I get stuff like this:
[0x7f24da6eb740: 0.00000 0] ENTER: (wrapper runtime-invoke) <Module>:runtime_invoke_void__this___object (object,intptr,intptr,intptr)([System.OutOfMemoryException:0x7f24da52af60], 0x7fff953e6510, (nil), 0x40e79a70, )
[0x7f24da6eb740: 0.00012 1] ENTER: System.OutOfMemoryException:.ctor (string)(this:0x7f24da52af60[System.OutOfMemoryException monotracetest.exe], [STRING:0x7f24da551e70:Out of memory], )
[0x7f24da6eb740: 0.00021 2] ENTER: System.SystemException:.ctor (string)(this:0x7f24da52af60[System.OutOfMemoryException monotracetest.exe], [STRING:0x7f24da551e70:Out of memory], )
[0x7f24da6eb740: 0.00030 3] ENTER: System.Exception:.ctor (string)(this:0x7f24da52af60[System.OutOfMemoryException monotracetest.exe], [STRING:0x7f24da551e70:Out of memory], )
[0x7f24da6eb740: 0.00031 3] LEAVE: System.Exception:.ctor (string)
..going on for nearly 900 lines about stack overflows, out of memory, and more innocent looking things.
I've not found any documentation on the trace option beyond '--help-trace'. What should I be expecting? Is this actually reporting problems? When I wrap the 'console.writeline("hello world")' in a try catch block, no exception is thrown. (Of course, presumably an unhandled exception would have crashed the program.)
My original program was to test calling a library of native code, and I reduced it to this to see where it failed.
How do I separate the wheat from the chaff?
That is the expected output: there is no exception thrown, but the runtime needs to build some objects at startup (for example the OutOfMemory exception object: when the condition happens there may be no memory anymore to allocate it!).
As for reducing the output, what is not clear in --help-trace?
For example, if you want to get traces only of classes and methods in the System.IO namespace, you will issue:
mono --trace=N:System.IO program.exe