I have this web view connected via IB in a garbage collected project. I can load a url perfectly fine in the web view one time, but then anytime after that one time it seems to crash randomly. I've got a couple different errors, a few specifically referencing garbage collection and saying EXC_BAD_ACCESS... the most recent and common though is this:
Thread 1, Queue : com.apple.main-thread
#0 0x00007fff8b4ffe90 in objc_msgSend ()
#1 0x00000004001ae2c0 in <????> ()
#2 0x00007fff97ab1313 in _NSURLConnectionDidReceiveData ()
#3 0x00007fff93e22388 in URLConnectionClient::_clientDidReceiveData(__CFArray const*, URLConnectionClient::ClientConnectionEventQueue*) ()
#4 0x00007fff93ed3c5b in URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload(XConnectionEventInfo<XClientEvent, XClientEventParams>*, long) ()
#5 0x00007fff93dfeb49 in URLConnectionClient::processEvents() ()
#6 0x00007fff93dfe9ee in MultiplexerSource::perform() ()
#7 0x00007fff8fd666e1 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ ()
#8 0x00007fff8fd65f4d in __CFRunLoopDoSources0 ()
#9 0x00007fff8fd8cd39 in __CFRunLoopRun ()
#10 0x00007fff8fd8c676 in CFRunLoopRunSpecific ()
#11 0x00007fff97a54f9f in -[NSRunLoop(NSRunLoop) runMode:beforeDate:] ()
#12 0x00007fff954861a2 in WebCore::ResourceHandle::loadResourceSynchronously(WebCore::NetworkingContext*, WebCore::ResourceRequest const&, WebCore::StoredCredentials, WebCore::ResourceError&, WebCore::ResourceResponse&, WTF::Vector<char, 0ul>&) ()
#13 0x00007fff95485c1f in WebCore::FrameLoader::loadResourceSynchronously(WebCore::ResourceRequest const&, WebCore::StoredCredentials, WebCore::ResourceError&, WebCore::ResourceResponse&, WTF::Vector<char, 0ul>&) ()
#14 0x00007fff9548583b in WebCore::DocumentThreadableLoader::loadRequest(WebCore::ResourceRequest const&, WebCore::SecurityCheckPolicy) ()
#15 0x00007fff95485376 in WebCore::DocumentThreadableLoader::DocumentThreadableLoader(WebCore::Document*, WebCore::ThreadableLoaderClient*, WebCore::DocumentThreadableLoader::BlockingBehavior, WebCore::ResourceRequest const&, WebCore::ThreadableLoaderOptions const&, WTF::String const&) ()
#16 0x00007fff95485220 in WebCore::DocumentThreadableLoader::loadResourceSynchronously(WebCore::Document*, WebCore::ResourceRequest const&, WebCore::ThreadableLoaderClient&, WebCore::ThreadableLoaderOptions const&) ()
#17 0x00007fff95485076 in WebCore::XMLHttpRequest::createRequest(int&) ()
#18 0x00007fff95484d07 in WebCore::XMLHttpRequest::send(WTF::String const&, int&) ()
#19 0x00007fff95484807 in WebCore::XMLHttpRequest::send(int&) ()
#20 0x00007fff954844e7 in WebCore::JSXMLHttpRequest::send(JSC::ExecState*) ()
#21 0x00007fff95484432 in WebCore::jsXMLHttpRequestPrototypeFunctionSend(JSC::ExecState*) ()
#22 0x00004f57b12011e8 in <????> ()
#23 0x00007fff900b778b in JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*) ()
#24 0x000000010c2e4da0 in <????> ()
#25 0x000000010a3f76a0 in <????> ()
#26 0x00007fff90286700 in JSC::JSFunction::~JSFunction() ()
#27 0x4810c08348eba9ab in <????> ()
I really don't know what to do. The crashing is sporadic and sometimes I can load the web view a few times before it crashes the app...
Also I've been getting this one a lot:
Thread 10, Queue : Garbage Collection Work Queue
#0 0x00007fff90168f6f in auto_fatal ()
#1 0x00007fff9017713b in Auto::Zone::handle_overretained_garbage(void*, int, int) ()
#2 0x00007fff90177844 in Auto::Zone::free_garbage(unsigned long, void**, unsigned long, void**, unsigned long&, unsigned long&) ()
#3 0x00007fff90164837 in auto_collect_internal(Auto::Zone*, unsigned int) ()
#4 0x00007fff9016021a in __auto_zone_collect_block_invoke_0 ()
#5 0x00007fff954098ba in _dispatch_call_block_and_release ()
#6 0x00007fff9540b10a in _dispatch_queue_drain ()
#7 0x00007fff9540af66 in _dispatch_queue_invoke ()
#8 0x00007fff9540a760 in _dispatch_worker_thread2 ()
#9 0x00007fff91adf3da in _pthread_wqthread ()
#10 0x00007fff91ae0b85 in start_wqthread ()
Related
I built the program by classic configure, make, make install. Some months after, the program crashed. I still have the build directory where both the source and the non-stripped executable reside. From there, I call gdb like so:
530-north:courier$ gdb -q --core /tmp/core_epoch\=1667475742_pid\=23653_file\=\!usr\!local\!libexec\!courier\!courierd courierd
Reading symbols from courierd...
[New LWP 23653]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/libexec/courier/courierd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000561e841e5afd in msgq::completed(drvinfo&, unsigned long) ()
(gdb) info args
No symbol table info available.
With bt I can see a long sequence of calls between two functions:
#0 0x0000561e841e5afd in msgq::completed(drvinfo&, unsigned long) ()
#1 0x0000561e841e609a in msgq::startdelivery(drvinfo*, delinfo*) ()
#2 0x0000561e841e5bd8 in msgq::completed(drvinfo&, unsigned long) ()
#3 0x0000561e841e609a in msgq::startdelivery(drvinfo*, delinfo*) ()
#4 0x0000561e841e5bd8 in msgq::completed(drvinfo&, unsigned long) ()
...
#204 0x0000561e841e5a17 in msgq::completed(drvinfo&, unsigned long) ()
#205 0x0000561e841e609a in msgq::startdelivery(drvinfo*, delinfo*) ()
#206 0x0000561e841e5a17 in msgq::completed(drvinfo&, unsigned long) ()
#207 0x0000561e841e70fe in courierbmain() ()
#208 0x0000561e841dd030 in main ()
Every couple of calls advances the stack by 0x110, for a total of ~27Kb, which is much less of the running processes' allocated 132Kb of stack, so it's not stack overflow. SIGSEGV could be from a null pointer or whatever. Why doesn't gdb point at it? This is GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git, BTW.
If I omit the last argument to gdb, bt doesn't show the function names. Did I screw up compilation? On config.log I see I had 'CFLAGS= -march=nocona -O2 -g' 'LDFLAGS= -march=nocona -O2' 'CXXFLAGS= -march=nocona -O2 -std=c++11'. The source file is C++. Perhaps I missed some -gs? Yet, some symbols are there...
Why doesn't gdb point at it?
Because you haven't compiled your program with appropriate debug info.
You'll have to debug this crash at the assembly level. Start with disasemble $pc and info registers.
The source file is C++. Perhaps I missed some -gs?
Yes: your CXXFLAGS don't have -g.
Yet, some symbols are there...
On UNIX systems (unlike Windows), function names (symbols) are present (by default) even without -g. There is no contradiction here.
Update:
However, if I don't pass the non-stripped file as argument, the function names are not displayed.
Yes: strip removes the symbols and debug info.
You can observe this by using a trivial test:
// t.cc
#include <cstdlib>
struct S {
void fn() { abort(); }
};
int main()
{
S().fn();
}
First let's see how it works when the binary is built correctly for debugging:
g++ -g t.cc -o a.out && strip ./a.out -o a.out.stripped &&
./a.out.stripped; gdb -q --batch -ex where ./a.out core
Aborted (core dumped)
...
warning: core file may not match specified executable file.
[New LWP 476070]
Core was generated by `./a.out.stripped'.
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=6, no_tid=no_tid#entry=0) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=6, no_tid=no_tid#entry=0) at ./nptl/pthread_kill.c:44
#1 0x00007f12444895df in __pthread_kill_internal (signo=<optimized out>, threadid=<optimized out>) at ./nptl/pthread_kill.c:89
#2 __GI___pthread_kill (threadid=<optimized out>, signo=<optimized out>) at ./nptl/pthread_kill.c:89
#3 0x00007f12445f5e70 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007f1244428469 in __GI_abort () at ./stdlib/abort.c:79
#5 0x000055de28a24165 in S::fn (this=0x7ffcd0d1d80f) at t.cc:4
#6 0x000055de28a2414d in main () at t.cc:9
Note presence of file/line info and function names. If we use the stripped version, neither is present:
ore was generated by `./a.out.stripped'.
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=6, no_tid=no_tid#entry=0) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=6, no_tid=no_tid#entry=0) at ./nptl/pthread_kill.c:44
#1 0x00007f12444895df in __pthread_kill_internal (signo=<optimized out>, threadid=<optimized out>) at ./nptl/pthread_kill.c:89
#2 __GI___pthread_kill (threadid=<optimized out>, signo=<optimized out>) at ./nptl/pthread_kill.c:89
#3 0x00007f12445f5e70 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007f1244428469 in __GI_abort () at ./stdlib/abort.c:79
#5 0x000055de28a24165 in ?? ()
#6 0x000055de28a2414d in ?? ()
#7 0x00007f124442920a in __libc_start_call_main (main=main#entry=0x55de28a24139, argc=argc#entry=1, argv=argv#entry=0x7ffcd0d1d928) at ../sysdeps/nptl/libc_start_call_main.h:58
#8 0x00007f12444292bc in __libc_start_main_impl (main=0x55de28a24139, argc=1, argv=0x7ffcd0d1d928, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcd0d1d918) at ../csu/libc-start.c:389
#9 0x000055de28a24071 in ?? ()
Now let's repeat with incorrectly built binary (which is what you have):
g++ t.cc -o b.out && strip ./b.out -o b.out.stripped &&
./b.out.stripped; gdb -q --batch -ex where ./b.out core
Aborted (core dumped)
...
warning: core file may not match specified executable file.
[New LWP 478614]
Core was generated by `./b.out.stripped'.
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=6, no_tid=no_tid#entry=0) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=6, no_tid=no_tid#entry=0) at ./nptl/pthread_kill.c:44
#1 0x00007f21a0a895df in __pthread_kill_internal (signo=<optimized out>, threadid=<optimized out>) at ./nptl/pthread_kill.c:89
#2 __GI___pthread_kill (threadid=<optimized out>, signo=<optimized out>) at ./nptl/pthread_kill.c:89
#3 0x00007f21a0bf5e70 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007f21a0a28469 in __GI_abort () at ./stdlib/abort.c:79
#5 0x000056049b052165 in S::fn() ()
#6 0x000056049b05214d in main ()
Notice presence of function names (S::fn(), main) but lack of file/line/argument info. This matches your observed result.
If you try again with b.out.stripped, you'll get the same result as you had from previous run with a.out.stripped:
Core was generated by `./b.out.stripped'.
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=6, no_tid=no_tid#entry=0) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=6, no_tid=no_tid#entry=0) at ./nptl/pthread_kill.c:44
#1 0x00007f21a0a895df in __pthread_kill_internal (signo=<optimized out>, threadid=<optimized out>) at ./nptl/pthread_kill.c:89
#2 __GI___pthread_kill (threadid=<optimized out>, signo=<optimized out>) at ./nptl/pthread_kill.c:89
#3 0x00007f21a0bf5e70 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007f21a0a28469 in __GI_abort () at ./stdlib/abort.c:79
#5 0x000056049b052165 in ?? ()
#6 0x000056049b05214d in ?? ()
#7 0x00007f21a0a2920a in __libc_start_call_main (main=main#entry=0x56049b052139, argc=argc#entry=1, argv=argv#entry=0x7fff3554bc78) at ../sysdeps/nptl/libc_start_call_main.h:58
#8 0x00007f21a0a292bc in __libc_start_main_impl (main=0x56049b052139, argc=1, argv=0x7fff3554bc78, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff3554bc68) at ../csu/libc-start.c:389
#9 0x000056049b052071 in ?? ()
In addition, readelf --debug-dump=info courierd shows lots of Version 4 stuff.
Yes, if you run readelf --debug-dump b.out, you could observe a lot of DWARF4 stuff coming from crt0.o, crtbegin.o, etc (depending on how your GCC and GLIBC were built).
If you have .c files linked in, these will also have DWARF4 debug info, since your CFLAGS do include -g.
But none of the DWARF4 stuff will be coming from wherever msgq::completed is defined.
Reference: tuttimer5
coliru demo
Based on the tutorial, the main function looks like the following:
int main()
{
boost::asio::io_context io;
printer p(io);
boost::thread t(boost::bind(&boost::asio::io_context::run, &io));
io.run(); // Why do we need to call io.run() here?
t.join();
return 0;
}
I want to understand why we need to have two io.run(); in the main function.
Here is my test result:
Test 1 (call io.run() in main thread within main function):
main-Thread #32
printer-Thread #32
print1-Thread #32
Timer 1: 0
print2-Thread #32
Timer 2: 1
print1-Thread #32
Timer 1: 2
print2-Thread #32
Timer 2: 3
print1-Thread #32
Timer 1: 4
print2-Thread #32
Timer 2: 5
print1-Thread #32
Timer 1: 6
print2-Thread #32
Timer 2: 7
print1-Thread #32
Timer 1: 8
print2-Thread #32
Timer 2: 9
~printer-Thread #32
Final count is 10
Observation1: both print1 and print2 are called by main-thread.
Test 2 (NOT call io.run() in main thread within main function):
main-Thread #40
printer-Thread #40
print1-Thread #29
Timer 1: 0
print2-Thread #29
Timer 2: 1
print1-Thread #29
Timer 1: 2
print2-Thread #29
Timer 2: 3
print1-Thread #29
Timer 1: 4
print2-Thread #29
Timer 2: 5
print1-Thread #29
Timer 1: 6
print2-Thread #29
Timer 2: 7
print1-Thread #29
Timer 1: 8
print2-Thread #29
Timer 2: 9
~printer-Thread #40
Final count is 10
Observation2: Neither print1 and print2 are called by main-thread.
Note: the testing results are come from my local linux box(g++ (Ubuntu 11.1.0-1ubuntu1~18.04.1) 11.1.0)). The result looks a little different from coliru.
In that case io_context operates like a classic thread pool.
Asynchronous tasks are performed somewhere on the OS side, however
completion handlers are invoked on those threads where io_context::run
function is running. To be more precise: every completion handler is
invoked on a first free thread which io_context::run function is
running on.
Question> what is the main reason that we want to call io.run); in both main and a new thread in the original tutorial?
Thank you
None of it is required. It merely shows that tasks are distributed over all thread participating in running/polling the execution context.
In that sense, the code as written is simply the cheapest way to get 2 threads running the io context. In a more recent Boost version, one could argue that thread_pool is cleaner code, but results in 3 threads (counting the main thread):
int main()
{
report("main") << std::endl;
boost::asio::thread_pool io(2);
printer p(io.get_executor());
io.join();
}
Live On Coliru
#include <boost/asio.hpp>
#include <boost/bind/bind.hpp>
#include <iomanip>
#include <iostream>
#include <thread>
namespace asio = boost::asio;
std::ostream& report(const std::string& suffix_msg)
{
auto tid = std::hash<std::thread::id>{}(std::this_thread::get_id()) % 100;
return std::cout << suffix_msg << "-Thread #" << std::setw(2)
<< std::setfill('0') << tid;
}
class printer {
public:
printer(asio::any_io_executor ex)
: strand_(asio::make_strand(ex))
, count_(0)
{
report("printer") << std::endl;
timer1_.async_wait(
std::bind(&printer::print_callback, this, "Timer 1", std::ref(timer1_)));
timer2_.async_wait(
std::bind(&printer::print_callback, this, "Timer 2", std::ref(timer2_)));
}
~printer()
{
report("~printer") << "\tFinal count is " << count_ << std::endl;
}
void print_callback(std::string_view name, asio::steady_timer& timer)
{
if (count_ < 10) {
report("print_callback") << "\t" << name << ": " << count_ << std::endl;
++count_;
timer.expires_at(timer.expiry() + asio::chrono::seconds(1));
timer.async_wait(std::bind(&printer::print_callback, this, name,
std::ref(timer)));
}
}
private:
asio::any_io_executor strand_;
int count_ = 0;
asio::steady_timer timer1_{strand_, asio::chrono::seconds(1)};
asio::steady_timer timer2_{strand_, asio::chrono::seconds(1)};
};
int main()
{
report("main") << std::endl;
boost::asio::thread_pool io(2);
printer p(io.get_executor());
io.join();
}
Prints e.g.
main-Thread #59
printer-Thread #59
print_callback-Thread #06 Timer 1: 0
print_callback-Thread #06 Timer 2: 1
print_callback-Thread #74 Timer 1: 2
print_callback-Thread #74 Timer 2: 3
print_callback-Thread #74 Timer 1: 4
print_callback-Thread #74 Timer 2: 5
print_callback-Thread #74 Timer 1: 6
print_callback-Thread #74 Timer 2: 7
print_callback-Thread #74 Timer 1: 8
print_callback-Thread #74 Timer 2: 9
~printer-Thread #59 Final count is 10
I met a very strange segfault and I does not understand the cause.
Context: in a console QT application, I need to create a PDF file containing some information but the PDF generation causes a segmentation fault.
I reduced the initial code to the main function and a method.
The qt .pro file:
CONFIG += console
CONFIG -= app_bundle
TEMPLATE = app
QT += core
QT += gui # need for pdf generation
QT += printsupport #need for pdf generation
main.cpp
int main(int argc, char *argv[])
{
QCoreApplication::setSetuidAllowed(true);
QCoreApplication app(argc, argv);
CPdfCreationDryRun pdfCreate(&app);
QTimer::singleShot(0, &pdfCreate, SLOT(start()));
return app.exec();
}
test.cpp
void CPdfCreationDryRun::start()
{
QTextDocument doc {};
const QString msg {"<p>toto</p>"};
doc.setHtml(msg);
const QString pdfFileName {"toto.pdf"};
QPrinter printer {QPrinter::PrinterResolution};
printer.setPageSize(QPrinter::A4);
printer.setOrientation(QPrinter::Portrait);
printer.setOutputFormat(QPrinter::PdfFormat);
printer.setOutputFileName(pdfFileName);
printer.setFontEmbeddingEnabled(true);
doc.print(&printer);
}
gdb backtrace
#0 0x00007f5cfec7bc42 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#1 0x00007f5cfec7f2cd in QFontDatabase::findFont(QFontDef const&, int) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#2 0x00007f5cfec7faf6 in QFontDatabase::load(QFontPrivate const*, int) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#3 0x00007f5cfec553b3 in QFontPrivate::engineForScript(int) const () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#4 0x00007f5cfec86cf9 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#5 0x00007f5cfeca0006 in QTextLine::layout_helper(int) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#6 0x00007f5cfeca1840 in QTextLine::setLineWidth(double) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#7 0x00007f5cfece4d3d in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#8 0x00007f5cfece5845 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#9 0x00007f5cfeceac3d in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#10 0x00007f5cfeceb0b9 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#11 0x00007f5cfeceb2b8 in QTextDocumentLayout::doLayout(int, int, int) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#12 0x00007f5cfecebde1 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#13 0x00007f5cfecec789 in QTextDocumentLayout::documentChanged(int, int, int) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#14 0x00007f5cfecb6bc6 in QTextDocument::documentLayout() const () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#15 0x00007f5cfecbe1ed in QTextDocument::print(QPagedPaintDevice*) const () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#16 0x0000559445993520 in CPdfCreationDryRun::start (this=0x7ffc7ea14be0) at
valgrind logs:
==82570== Invalid read of size 8
==82570== at 0x54A8C42: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54AC2CC: QFontDatabase::findFont(QFontDef const&, int) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54ACAF5: QFontDatabase::load(QFontPrivate const*, int) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54823B2: QFontPrivate::engineForScript(int) const (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54B7617: QTextEngine::fontEngine(QScriptItem const&, QFixed*, QFixed*, QFixed*) const (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54B8708: QTextEngine::shapeText(int) const (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54B93EE: QTextEngine::shape(int) const (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54CDDFB: QTextLine::layout_helper(int) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54CE83F: QTextLine::setLineWidth(double) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x5511D3C: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x5512844: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x5517C3C: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==82570==
==82570==
==82570== Process terminating with default action of signal 11 (SIGSEGV)
==82570== Access not within mapped region at address 0x0
==82570== at 0x54A8C42: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54AC2CC: QFontDatabase::findFont(QFontDef const&, int) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54ACAF5: QFontDatabase::load(QFontPrivate const*, int) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54823B2: QFontPrivate::engineForScript(int) const (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54B7617: QTextEngine::fontEngine(QScriptItem const&, QFixed*, QFixed*, QFixed*) const (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54B8708: QTextEngine::shapeText(int) const (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54B93EE: QTextEngine::shape(int) const (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54CDDFB: QTextLine::layout_helper(int) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x54CE83F: QTextLine::setLineWidth(double) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x5511D3C: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x5512844: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
==82570== by 0x5517C3C: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5)
I tried to redefine QT_QPA_FONTDIR env variable to different directories containing fonts but this did not change the behavior.
EDIT1: I tried without "printer.setFontEmbeddingEnabled()" and it did not change the behavior.
EDIT2: The doc variable content:
doc.toHtml: "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\" \"http://www.w3.org/TR/REC-html40/strict.dtd\">\n<html><head><meta name=\"qrichtext\" content=\"1\" /><style type=\"text/css\">\np, li { white-space: pre-wrap; }\n</style></head><body style=\" font-family:''; font-weight:400; font-style:normal;\">\n<p style=\" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;\">toto</p></body></html>"
doc.toPlainText: "toto"
doc.toRaw: "toto"
Host configuration:
Linux ubuntu 4.18.0-25-generic #26~18.04.1-Ubuntu SMP Thu Jun 27 07:28:31 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
g++ --version
g++ (Ubuntu 8.3.0-6ubuntu1~18.04.1) 8.3.0
QT: 5.9.5-0ubuntu1
I am looking for any helps to understand the observed behavior and how to fix it.
Thanks & regards,
I found a workaround: I replaced
QCoreApplication
per
QApplication
then rebuilt... And it works :'(
Consider following (broken) code:
#include <iostream>
#include <memory>
using namespace std;
class Test {
public:
unique_ptr<string> s;
Test() : s(NULL) {
}
void update(string& st) {
s = unique_ptr<string>(&(st));
}
};
void update(Test& t) {
string s("Hello to you");
t.update(s);
}
int main() {
Test t;
update(t);
cout << *t.s << endl;
}
Here we have error in method Test::update() we do not make a uniq copy of an object. So when the program is run under macOS, you'll get:
$ ./test
Hello t��E]�
test(44981,0x7fff99ba93c0) malloc: *** error for object 0x7fff5d45b690: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
[1] 44981 abort ./test
I've been able to to debug this case successfully using lldb. Even without setting a breakpoint in malloc_error_break, just running application until it gets caught in SIGABRT handler.
lldb ./test
(lldb) target create "./test"
Current executable set to './test' (x86_64).
(lldb) run
Process 44993 launched: './test' (x86_64)
Hello t��_�
test(44993,0x7fff99ba93c0) malloc: *** error for object 0x7fff5fbff680: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Process 44993 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x00007fff90d6cd42 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
-> 0x7fff90d6cd42 <+10>: jae 0x7fff90d6cd4c ; <+20>
0x7fff90d6cd44 <+12>: movq %rax, %rdi
0x7fff90d6cd47 <+15>: jmp 0x7fff90d65caf ; cerror_nocancel
0x7fff90d6cd4c <+20>: retq
Target 0: (test) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
* frame #0: 0x00007fff90d6cd42 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007fff90e5a457 libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x00007fff90cd2420 libsystem_c.dylib`abort + 129
frame #3: 0x00007fff90dc1fe7 libsystem_malloc.dylib`free + 530
frame #4: 0x0000000100001f7b test`Test::~Test() [inlined] std::__1::default_delete<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::operator(this=0x00007fff5fbff730, __ptr="\a\x94\x99�\x7f\0\0��_�\x7f\0\0\x80�_�\x7f\0\00�_�\x7f\0\00�_�\x7f\0\00�_�\x7f\0\00�_�\x7f\0\00�_�\x7f\0\0��_�\x7f\0\0\x15\x1e\0\0\x01\0\0\0\x80�_�\x7f\0\n0")(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*) const at memory:2397
frame #5: 0x0000000100001f46 test`Test::~Test() [inlined] std::__1::unique_ptr<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::default_delete<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::reset(this=0x00007fff5fbff730, __p="") at memory:2603
frame #6: 0x0000000100001ef3 test`Test::~Test() [inlined] std::__1::unique_ptr<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::default_delete<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::~unique_ptr(this=0x00007fff5fbff730) at memory:2571
frame #7: 0x0000000100001ef3 test`Test::~Test() [inlined] std::__1::unique_ptr<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::default_delete<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::~unique_ptr(this=0x00007fff5fbff730) at memory:2571
frame #8: 0x0000000100001ef3 test`Test::~Test(this=0x00007fff5fbff730) at main.cpp:6
frame #9: 0x0000000100001e15 test`Test::~Test(this=0x00007fff5fbff730) at main.cpp:6
frame #10: 0x0000000100001ab6 test`main at main.cpp:28
frame #11: 0x00007fff90c3e235 libdyld.dylib`start + 1
Now I see that the problem is in Test destructor, and from here it's a piece of cake.
Unfortunately, trying to debug this case using gdb under macOS was a total failure. Here is what I've done:
$ gdb ./test
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin16.7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test...Reading symbols from /Users/bazhenov/Developer/linear-counter/tests/test/test.dSYM/Contents/Resources/DWARF/test...done.
done.
(gdb) run
Starting program: /Users/bazhenov/Developer/linear-counter/tests/test/test
[New Thread 0x1403 of process 45204]
warning: unhandled dyld version (15)
Hello tQ�_�
test(45204,0x7fff99ba93c0) malloc: *** error for object 0x7fff5fbff650: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Thread 2 received signal SIGABRT, Aborted.
0x00007fff90d6cd42 in ?? ()
(gdb) bt
#0 0x00007fff90d6cd42 in ?? ()
#1 0x00007fff90e5a457 in ?? ()
#2 0x00007fff5fbff590 in ?? ()
#3 0x0000030700000000 in ?? ()
#4 0x00007fff5fbff590 in ?? ()
#5 0x00007fff5fbff650 in ?? ()
#6 0x00007fff5fbff5a0 in ?? ()
#7 0x00007fff90cd2420 in ?? ()
#8 0xffffffff00000018 in ?? ()
#9 0x00007fff5fbff5b0 in ?? ()
#10 0x00007fffffffffdf in ?? ()
#11 0x00000001000c4000 in ?? ()
#12 0x00007fff5fbff5f0 in ?? ()
#13 0x00007fff90dc1fe7 in ?? ()
#14 0x378b45e65b700074 in ?? ()
#15 0x00007fff99ba00ac in ?? ()
#16 0x0000000000000000 in ?? ()
(gdb)
The question is: why gdb fails to unwind the stack correctly and what options do I have if I need to get correct backtrace using gdb?
why gdb fails to unwind the stack correctly
There are some problems on Mac OS X Sierra with gdb, see this post and gdb bug report.
what options do I have if I need to get correct backtrace using gdb
You can try to downgrade Mac OS (don't know whether is it possible) or try to apply temporary hack patch from above bug report.
I am trying to start sample-Groceries from here http://docs.nativescript.org/angular/tutorial/ng-chapter-1 on android emulator and get the following message "unfortunately, Groceries has stoped"
Here is the debug messages from console
I/DEBUG ( 1142): #12 pc 005c13b1 /data/app/org.nativescript.groceries-1/lib/x86/libNativeScript.so (v8::internal::RegExpImpl::CompileIrregexp(v8::internal::Handle<v8::internal::JSRegExp>, v8::internal::Handle<v8::internal::String>, bool)+673)
I/DEBUG ( 1142): #13 pc 005c1605 /data/app/org.nativescript.groceries-1/lib/x86/libNativeScript.so (v8::internal::RegExpImpl::IrregexpPrepare(v8::internal::Handle<v8::internal::JSRegExp>, v8::internal::Handle<v8::internal::String>)+165)
I/DEBUG ( 1142): #14 pc 005c1b23 /data/app/org.nativescript.groceries-1/lib/x86/libNativeScript.so (v8::internal::RegExpImpl::IrregexpExec(v8::internal::Handle<v8::internal::JSRegExp>, v8::internal::Handle<v8::internal::String>, int, v8::internal::Handle<v8::internal::JSArray>)+51)
I/DEBUG ( 1142): #15 pc 005c1cd0 /data/app/org.nativescript.groceries-1/lib/x86/libNativeScript.so (v8::internal::RegExpImpl::Exec(v8::internal::Handle<v8::internal::JSRegExp>, v8::internal::Handle<v8::internal::String>, int, v8::internal::Handle<v8::internal::JSArray>)+144)
I/DEBUG ( 1142): #12 pc 005c13b1 /data/app/org.nativescript.groceries-1/lib/x86/libNativeScript.so (v8::internal::RegExpImpl::CompileIrregexp(v8::internal::Handle<v8::internal::JSRegExp>, v8::internal::Handle<v8::internal::String>, bool)+673)
I/DEBUG ( 1142): #13 pc 005c1605 /data/app/org.nativescript.groceries-1/lib/x86/libNativeScript.so (v8::internal::RegExpImpl::IrregexpPrepare(v8::internal::Handle<v8::internal::JSRegExp>, v8::internal::Handle<v8::internal::String>)+165)
I/DEBUG ( 1142): #14 pc 005c1b23 /data/app/org.nativescript.groceries-1/lib/x86/libNativeScript.so (v8::internal::RegExpImpl::IrregexpExec(v8::internal::Handle<v8::internal::JSRegExp>, v8::internal::Handle<v8::internal::String>, int, v8::internal::Handle<v8::internal::JSArray>)+51)
I/DEBUG ( 1142): #15 pc 005c1cd0 /data/app/org.nativescript.groceries-1/lib/x86/libNativeScript.so (v8::internal::RegExpImpl::Exec(v8::internal::Handle<v8::internal::JSRegExp>, v8::internal::Handle<v8::internal::String>, int, v8::internal::Handle<v8::internal::JSArray>)+144)
I/DEBUG ( 1142): #12 pc 005c13b1 /data/app/org.nativescript.groceries-1/lib/x86/libNativeScript.so (v8::internal::RegExpImpl::CompileIrregexp(v8::internal::Handle<v8::internal::JSRegExp>, v8::internal::Handle<v8::internal::String>, bool)+673)
I/DEBUG ( 1142): #13 pc 005c1605 /data/app/org.nativescript.groceries-1/lib/x86/libNativeScript.so (v8::internal::RegExpImpl::IrregexpPrepare(v8::internal::Handle<v8::internal::JSRegExp>, v8::internal::Handle<v8::internal::String>)+165)
I/DEBUG ( 1142): #14 pc 005c1b23 /data/app/org.nativescript.groceries-1/lib/x86/libNativeScript.so (v8::internal::RegExpImpl::IrregexpExec(v8::internal::Handle<v8::internal::JSRegExp>, v8::internal::Handle<v8::internal::String>, int, v8::internal::Handle<v8::internal::JSArray>)+51)
I/DEBUG ( 1142): #15 pc 005c1cd0 /data/app/org.nativescript.groceries-1/lib/x86/libNativeScript.so (v8::internal::RegExpImpl::Exec(v8::internal::Handle<v8::internal::JSRegExp>, v8::internal::Handle<v8::internal::String>, int, v8::internal::Handle<v8::internal::JSArray>)+144)
I tried to use Genymotion and native android emulator
Ubuntu 16.04 node.js 4.5.0
tns --version 2.2.1
I reviewed the given scenario, however I was unable to reproduce such a problem with the getting started project and new created projects. Could you follow the below attached steps to verify whether this helps.
tns create sampleProject --ng
manually start android emulator
tns prepare android
run tns run android