I get a gdb backtrace shown below consistently. Would this indicate a failure in doing malloc( ) ? If so, I also let a "free -m" run on the Linux box and I can't seem to find a discrepancy. xsd__anyType is a typedef of soap_dom_element
(gdb) bt
#0 0x0000007f9af24090 in raise () from /tmp/../lib/libc.so.6
#1 0x0000007f9af12894 in abort () from /tmp/../lib/libc.so.6
#2 0x0000007f9af5c950 in ?? () from /tmp/../lib/libc.so.6
#3 0x0000007f9af62d64 in ?? () from /tmp/../lib/libc.so.6
#4 0x0000007f9af66158 in ?? () from /tmp/../lib/libc.so.6
#5 0x0000007f9af67550 in malloc () from /tmp/../lib/libc.so.6
#6 0x0000007f9b8b909c in soap_malloc () from /opt/ad/lib/libjci_gsoap.so
#7 0x0000007f9b8d4d40 in ?? () from /opt/ad/lib/libjci_gsoap.so
#8 0x0000007f9b8d5834 in soap_in_xsd__anyType(soap*, char const*, soap_dom_element*, char const*) () from /opt/ad/lib/libjci_gsoap.so
#9 0x0000007f9b8d5874 in soap_in_xsd__anyType(soap*, char const*, soap_dom_element*, char const*) () from /opt/ad/lib/libjci_gsoap.so
#10 0x0000007f9b8d5874 in soap_in_xsd__anyType(soap*, char const*, soap_dom_element*, char const*) () from /opt/ad/lib/libjci_gsoap.so
#11 0x0000007f9b8d5874 in soap_in_xsd__anyType(soap*, char const*, soap_dom_element*, char const*) () from /opt/ad/lib/libjci_gsoap.so
#12 0x0000007f9b8d6fe4 in operator>>(std::istream&, soap_dom_element&) () from /opt/ad/lib/libjci_gsoap.so
#13 0x0000000000507274 in tev::Events::getSubscriptionReference[abi:cxx11](char const*) const (this=this#entry=0x7f99eb25b0,
msgBuf=0x7f99ec0218 "POST /onvif/event_service HTTP/1.0\r\nContent-Type: application/soap+xml; charset=utf-8\r\nHost: 192.168.184.35\r\nContent-Length: 1438\r\nAccept-Encoding: gzip, deflate\r\nX-Forwarded-For: ::ffff:192.168.185.1"...) at /home/jbloomrp/sandboxes/acvs-illustra-global/toolchain/arm/linaro-aarch64-2018.08-gcc8.2/work/amb_cv22_evk/arm/release/linaro-aarch64-2018.08-gcc8.2/aarch64-linux-gnu/include/c++/8.2.1/bits/unique_ptr.h:342
If malloc is a failure, then I should see it spiral towards 0 which doesn't seem to be the case.
Swap: 0 0 0
total used free shared buff/cache available
Mem: 1983 995 703 147 285 826
Swap: 0 0 0
total used free shared buff/cache available
Mem: 1983 1038 659 147 285 782
Swap: 0 0 0
Even at the lowest I could see free mem was still 659.
Related
I was able to compile and run my application on this Mac with the specified setup. From one day to another I couldn't execute the application (even in Debug mode). The error occurs without any actual signing besides the things that are happening in the default debug/release build.
What I've tried to solve this issue:
Made clean builds, even re-cloned the repository
Restarted the MacBook (as specified in the official MacOS docs according to this signing error)
Reinstalled QtCreator
Run system updates (e.g. for the console tools)
I ran out of ideas what to do next. Any input is appreciated. In the following there is the MacOS crash report:
Process: Sample [6739]
Path: /Users/USER/*/Sample.app/Contents/MacOS/Sample
Identifier: com.yourcompany.Sample
Version: ???
Code Type: ARM-64 (Native)
Parent Process: qtcreator_processlauncher [6187]
User ID: 501
Date/Time: 2022-06-10 09:56:06.0533 +0200
OS Version: macOS 12.4 (21F79)
Report Version: 12
Anonymous UUID: 3C17814C-6324-03D6-2715-B4F55ACF44E5
Sleep/Wake UUID: 74437E44-7126-4975-8C2B-014AB410B1BE
Time Awake Since Boot: 35000 seconds
Time Since Wake: 6363 seconds
System Integrity Protection: enabled
Crashed Thread: 0
Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))
Exception Codes: UNKNOWN_0x32 at 0x0000000100db0000
Exception Codes: 0x0000000000000032, 0x0000000100db0000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace CODESIGNING, Code 2
VM Region Info: 0x100db0000 is in 0x100db0000-0x100dd0000; bytes after start: 0 bytes before end: 131071
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
mapped file 100d74000-100db0000 [ 240K] r--/rwx SM=COW ...t_id=e753674d
---> mapped file 100db0000-100dd0000 [ 128K] r-x/rwx SM=COW ...t_id=e753674d
VM_ALLOCATE (reserved) 100dd0000-100dec000 [ 112K] rw-/rwx SM=NUL ...(unallocated)
Thread 0 Crashed:
0 dyld 0x100fa8008 dyld3::MachOFile::isMachO(Diagnostics&, unsigned long long) const + 20
1 dyld 0x100f892cc dyld4::Loader::mapSegments(Diagnostics&, dyld4::RuntimeState&, char const*, unsigned long long, dyld4::Loader::CodeSignatureInFile const&, bool, dyld3::Array<dyld4::Loader::Region> const&, bool, bool, dyld4::Loader::FileValidationInfo const&) + 1096
2 dyld 0x100f892cc dyld4::Loader::mapSegments(Diagnostics&, dyld4::RuntimeState&, char const*, unsigned long long, dyld4::Loader::CodeSignatureInFile const&, bool, dyld3::Array<dyld4::Loader::Region> const&, bool, bool, dyld4::Loader::FileValidationInfo const&) + 1096
3 dyld 0x100f8eb88 invocation function for block in dyld4::JustInTimeLoader::makeJustInTimeLoaderDisk(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&, bool, unsigned int) + 68
4 dyld 0x100f8e528 dyld4::JustInTimeLoader::withRegions(dyld3::MachOAnalyzer const*, void (dyld3::Array<dyld4::Loader::Region> const&) block_pointer) + 292
5 dyld 0x100f8eadc invocation function for block in dyld4::JustInTimeLoader::makeJustInTimeLoaderDisk(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&, bool, unsigned int) + 480
6 dyld 0x100f93d58 dyld4::SyscallDelegate::withReadOnlyMappedFile(Diagnostics&, char const*, bool, void (void const*, unsigned long, bool, dyld4::FileID const&, char const*) block_pointer) const + 132
7 dyld 0x100f8e8c8 dyld4::JustInTimeLoader::makeJustInTimeLoaderDisk(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&, bool, unsigned int) + 204
8 dyld 0x100f886d0 invocation function for block in dyld4::Loader::getLoader(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&) + 1384
9 dyld 0x100f87bc0 dyld4::Loader::forEachResolvedAtPathVar(dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&, dyld4::ProcessConfig::PathOverrides::Type, bool&, void (char const*, dyld4::ProcessConfig::PathOverrides::Type, bool&) block_pointer) + 780
10 dyld 0x100f877ec invocation function for block in dyld4::Loader::forEachPath(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&, void (char const*, dyld4::ProcessConfig::PathOverrides::Type, bool&) block_pointer) + 148
11 dyld 0x100f7db18 dyld4::ProcessConfig::PathOverrides::forEachImageSuffix(char const*, dyld4::ProcessConfig::PathOverrides::Type, bool&, void (char const*, dyld4::ProcessConfig::PathOverrides::Type, bool&) block_pointer) const + 176
12 dyld 0x100f7e34c invocation function for block in dyld4::ProcessConfig::PathOverrides::forEachPathVariant(char const*, dyld3::Platform, bool, bool&, void (char const*, dyld4::ProcessConfig::PathOverrides::Type, bool&) block_pointer) const + 160
13 dyld 0x100f7d0f0 dyld4::ProcessConfig::PathOverrides::forEachInColonList(char const*, char const*, void (char const*, bool&) block_pointer) + 204
14 dyld 0x100f7dd9c dyld4::ProcessConfig::PathOverrides::forEachPathVariant(char const*, dyld3::Platform, bool, bool&, void (char const*, dyld4::ProcessConfig::PathOverrides::Type, bool&) block_pointer) const + 344
15 dyld 0x100f87740 dyld4::Loader::forEachPath(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&, void (char const*, dyld4::ProcessConfig::PathOverrides::Type, bool&) block_pointer) + 172
16 dyld 0x100f87f60 dyld4::Loader::getLoader(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&) + 864
17 dyld 0x100f8cb60 invocation function for block in dyld4::JustInTimeLoader::loadDependents(Diagnostics&, dyld4::RuntimeState&, dyld4::Loader::LoadOptions const&) + 380
18 dyld 0x100fa9264 invocation function for block in dyld3::MachOFile::forEachDependentDylib(void (char const*, bool, bool, bool, unsigned int, unsigned int, bool&) block_pointer) const + 148
19 dyld 0x100f75f98 dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 168
20 dyld 0x100fa90ac dyld3::MachOFile::forEachDependentDylib(void (char const*, bool, bool, bool, unsigned int, unsigned int, bool&) block_pointer) const + 172
21 dyld 0x100f8c8c8 dyld4::JustInTimeLoader::loadDependents(Diagnostics&, dyld4::RuntimeState&, dyld4::Loader::LoadOptions const&) + 164
22 dyld 0x100f795c0 dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 1092
23 dyld 0x100f7906c start + 488
Thread 0 crashed with ARM Thread State (64-bit):
x0: 0x0000000100db0000 x1: 0x000000016f6edcd8 x2: 0x0000000000020000 x3: 0x0000000000040012
x4: 0x0000000000000003 x5: 0x0000000000000000 x6: 0x0000000000000000 x7: 0x0000000000000000
x8: 0x0000000100fec62c x9: 0x0000000100fedea8 x10: 0x000000001e000000 x11: 0x0800000000028000
x12: 0x0000000000000001 x13: 0x0000000000000001 x14: 0x0000000000011b00 x15: 0x0000000000000000
x16: 0x00000000000000c5 x17: 0x6ae100016f6ed4b8 x18: 0x0000000000000000 x19: 0x000000016f6edcd8
x20: 0x0000000100c70060 x21: 0x000000000003c000 x22: 0x0000000000000003 x23: 0x000000016f6ed7c8
x24: 0x0000000000000040 x25: 0x0000000000000000 x26: 0x000000016f6ed54c x27: 0x0000000000000000
x28: 0x0000000100db0000 fp: 0x000000016f6ed110 lr: 0x7a6f800100f892cc
sp: 0x000000016f6ed100 pc: 0x0000000100fa8008 cpsr: 0x00001000
far: 0x0000000100db0000 esr: 0x92000007 (Data Abort) byte read Translation fault
Binary Images:
0x100f74000 - 0x100fd3fff dyld (*) <d9c2a46e-8dc4-3950-9d6a-f799e8ccb683> /usr/lib/dyld
0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
VM Region Summary:
ReadOnly portion of Libraries: Total=6048K resident=0K(0%) swapped_out_or_unallocated=6048K(100%)
Writable regions: Total=9360K written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=9360K(100%)
This is the $ codesign output:
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20400 size=43712 flags=0x20002(adhoc,linker-signed) hashes=1363+0 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=250886c9e93ae2aa977a592f451a52885ecd1701
CandidateCDHashFull sha256=250886c9e93ae2aa977a592f451a52885ecd17015c94bbeafa49d2cbb2274ed3
Hash choices=sha256
CMSDigest=250886c9e93ae2aa977a592f451a52885ecd17015c94bbeafa49d2cbb2274ed3
CMSDigestType=2
CDHash=250886c9e93ae2aa977a592f451a52885ecd1701
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none
I have a crash in application:
__cxxabiv1::__cxa_pure_virtual ()
I can understand
What is the meaning of a "pure virtual" call in a stack trace?
And according "1 Answer" below i can exercise a little test program:
1 #include <iostream>
2
3 class Base
4 {
5 public:
6 Base()
7 {
8 std::cout << "Base c'tor" << std::endl;
9 }
10
11 virtual ~Base()
12 {
13 std::cout << "Base d'tor" << std::endl;
14 }
15
16 };
17
18 class Derived : public Base
19 {
20 public:
21 Derived()
22 : Base()
23 {
24 std::cout << "Derived c'tor" << std::endl;
25 }
26
27 ~Derived()
28 {
29 std::cout << "Derived d'tor" << std::endl;
30 }
31 };
32
33 int
34 main(
35 int,
36 char**)
37 {
38 {
39 Derived d;
40 }
41 return 0;
42 }
compile with:
g++ -g3 -O0 -o test test.cc
create gdb batch script:
break 8
command
p this
x/10xg this
x/10xg (long)*this
cont
end
break 13
command
p this
x/10xg this
x/10xg (long)*this
cont
end
break 24
command
p this
x/10xg this
x/10xg (long)*this
cont
end
break 29
command
p this
x/10xg this
x/10xg (long)*this
cont
end
run
and run:
frank#frank-PC:~$ gdb ./test < gdb.bat |c++filt
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 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-linux-gnu".
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...done.
(gdb) Breakpoint 1 at 0x400b72: file test.cc, line 8.
(gdb) >>>>>(gdb) Breakpoint 2 at 0x400baa: file test.cc, line 13.
(gdb) >>>>>(gdb) Breakpoint 3 at 0x400c29: file test.cc, line 24.
(gdb) >>>>>(gdb) Breakpoint 4 at 0x400c81: file test.cc, line 29.
(gdb) >>>>>(gdb) Starting program: /home/frank/test
Breakpoint 1, Base::Base (this=0x7fffffffdab0) at test.cc:8
8 std::cout << "Base c'tor" << std::endl;
$1 = (Base * const) 0x7fffffffdab0
0x7fffffffdab0: 0x0000000000400df8 0x597870ad9bc42900
0x7fffffffdac0: 0x0000000000400d10 0x00007ffff7495830
0x7fffffffdad0: 0x0000000000000000 0x00007fffffffdba8
0x7fffffffdae0: 0x00000001ffffdbb8 0x0000000000400ab6
0x7fffffffdaf0: 0x0000000000000000 0x9e98039144430dd4
0x400df8 <vtable for Base+16>: 0x0000000000400b92 0x0000000000400bde
0x400e08 <typeinfo for Derived>: 0x0000000000602200 0x0000000000400e20
0x400e18 <typeinfo for Derived+16>: 0x0000000000400e30 0x6465766972654437
0x400e28 <typeinfo name for Derived+8>: 0x0000000000000000 0x0000000000602090
0x400e38 <typeinfo for Base+8>: 0x0000000000400e40 0x0000006573614234
Base c'tor
Breakpoint 3, Derived::Derived (this=0x7fffffffdab0) at test.cc:24
24 std::cout << "Derived c'tor" << std::endl;
$2 = (Derived * const) 0x7fffffffdab0
0x7fffffffdab0: 0x0000000000400dd8 0x597870ad9bc42900
0x7fffffffdac0: 0x0000000000400d10 0x00007ffff7495830
0x7fffffffdad0: 0x0000000000000000 0x00007fffffffdba8
0x7fffffffdae0: 0x00000001ffffdbb8 0x0000000000400ab6
0x7fffffffdaf0: 0x0000000000000000 0x9e98039144430dd4
0x400dd8 <vtable for Derived+16>: 0x0000000000400c68 0x0000000000400ce2
0x400de8 <vtable for Base>: 0x0000000000000000 0x0000000000400e30
0x400df8 <vtable for Base+16>: 0x0000000000400b92 0x0000000000400bde
0x400e08 <typeinfo for Derived>: 0x0000000000602200 0x0000000000400e20
0x400e18 <typeinfo for Derived+16>: 0x0000000000400e30 0x6465766972654437
Derived c'tor
Breakpoint 4, Derived::~Derived (this=0x7fffffffdab0, __in_chrg=<optimized out>) at test.cc:29
29 std::cout << "Derived d'tor" << std::endl;
$3 = (Derived * const) 0x7fffffffdab0
0x7fffffffdab0: 0x0000000000400dd8 0x597870ad9bc42900
0x7fffffffdac0: 0x0000000000400d10 0x00007ffff7495830
0x7fffffffdad0: 0x0000000000000000 0x00007fffffffdba8
0x7fffffffdae0: 0x00000001ffffdbb8 0x0000000000400ab6
0x7fffffffdaf0: 0x0000000000000000 0x9e98039144430dd4
0x400dd8 <vtable for Derived+16>: 0x0000000000400c68 0x0000000000400ce2
0x400de8 <vtable for Base>: 0x0000000000000000 0x0000000000400e30
0x400df8 <vtable for Base+16>: 0x0000000000400b92 0x0000000000400bde
0x400e08 <typeinfo for Derived>: 0x0000000000602200 0x0000000000400e20
0x400e18 <typeinfo for Derived+16>: 0x0000000000400e30 0x6465766972654437
Derived d'tor
Breakpoint 2, Base::~Base (this=0x7fffffffdab0, __in_chrg=<optimized out>) at test.cc:13
13 std::cout << "Base d'tor" << std::endl;
$4 = (Base * const) 0x7fffffffdab0
0x7fffffffdab0: 0x0000000000400df8 0x597870ad9bc42900
0x7fffffffdac0: 0x0000000000400d10 0x00007ffff7495830
0x7fffffffdad0: 0x0000000000000000 0x00007fffffffdba8
0x7fffffffdae0: 0x00000001ffffdbb8 0x0000000000400ab6
0x7fffffffdaf0: 0x0000000000000000 0x9e98039144430dd4
0x400df8 <vtable for Base+16>: 0x0000000000400b92 0x0000000000400bde
0x400e08 <typeinfo for Derived>: 0x0000000000602200 0x0000000000400e20
0x400e18 <typeinfo for Derived+16>: 0x0000000000400e30 0x6465766972654437
0x400e28 <typeinfo name for Derived+8>: 0x0000000000000000 0x0000000000602090
0x400e38 <typeinfo for Base+8>: 0x0000000000400e40 0x0000006573614234
Base d'tor
[Inferior 1 (process 4962) exited normally]
(gdb) (gdb) quit
But the stacktrace for my real application (not the little demo above) hits:
__cxxabiv1::__cxa_pure_virtual ()
while the last d'tor i see on the call stack is the derived class.
So is this an indicator, that memory object was already free'd and re-used again for some other object instance?
How can that be? Is such done by the compiler for intermediate work?
Yes. Typically, a constructor first sets the vtable pointer to its own class's vtable. Then, when the derived class's constructor runs, it overwrites the vtable pointer with its own.
This achieves exactly the behavior that the C++ standard requires, that calls to virtual functions during the execution of constructors (and destructors; they reverse these assignments) treat the objects as having the dynamic type of the constructor, not the actual complete object. And in the case of pure virtual functions, the behavior is undefined; compilers typically insert this diagnostic stub in the vtable.
I have an library that don't give correct output. I guess it is possibly an write violation, and focused it on this section of code:
void Page::build_default_frame(PosType genome_display_length)
{
Frame* frame = new Frame(*this,
margin_left,
margin_top,
width - margin_left - margin_right,
genome_display_length);
default_frame = frame;
frames.insert(default_frame);
}
The default_frame is a boost intrusive_ptr<Frame>.
Before execute the sentence default_frame = frame, the content of object frame was all right, but after that, its contents were modified to weird value. So I set two watches on two member variables of frame object:
(gdb) watch -l frame->genome_scale.genome_display_length
Hardware watchpoint 4: -location frame->genome_scale.genome_display_length
(gdb) watch -l frame->genome_scale.frame_width
Hardware watchpoint 5: -location frame->genome_scale.frame_width
and then continue. It suddenly reports write operation on these address:
(gdb) c
Continuing.
Hardware watchpoint 4: -location frame->genome_scale.genome_display_length
Old value = 1000
New value = 16
_dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:39
39 ../sysdeps/x86_64/dl-trampoline.S: No such file or directory.
(gdb) bt
#0 _dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:39
#1 0x00007ffff7b93dd0 in geno_eye::Page::build_default_frame (this=0x6071b0, genome_display_length=1000)
at /home/yangxi/projects/GenoEye/src/geno_eye/Page.cpp:127
#2 0x00007ffff7b93cc1 in geno_eye::Page::Page (this=0x6071b0, context=0x607750, width=300, height=300,
genome_display_length=1000) at /home/yangxi/projects/GenoEye/src/geno_eye/Page.cpp:29
#3 0x00000000004016b8 in geno_eye::__tester__::run (this=0x7fffffffe1c8)
at /home/yangxi/projects/GenoEye/t/t_page.cpp:15
#4 0x00000000004015d1 in main () at /home/yangxi/projects/GenoEye/t/t_page.cpp:36
(gdb) c
Continuing.
Hardware watchpoint 5: -location frame->genome_scale.frame_width
Old value = 240
New value = 3.1228427039313504e-317
_dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:40
40 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) bt
#0 _dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:40
#1 0x00007ffff7b93dd0 in geno_eye::Page::build_default_frame (this=0x6071b0, genome_display_length=1000)
at /home/yangxi/projects/GenoEye/src/geno_eye/Page.cpp:127
#2 0x00007ffff7b93cc1 in geno_eye::Page::Page (this=0x6071b0, context=0x607750, width=300, height=300,
genome_display_length=1000) at /home/yangxi/projects/GenoEye/src/geno_eye/Page.cpp:29
#3 0x00000000004016b8 in geno_eye::__tester__::run (this=0x7fffffffe1c8)
at /home/yangxi/projects/GenoEye/t/t_page.cpp:15
#4 0x00000000004015d1 in main () at /home/yangxi/projects/GenoEye/t/t_page.cpp:36
The two old values are the correct values for that two member variables. This write operation is happened before executing the = function of boost intrusive_ptr, as I pressed tens of "next", and the code is still in file dl-trampoline.S.
(gdb) n
41 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) n
42 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) n
43 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) n
44 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) n
45 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) n
46 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) n
47 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) n
48 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) n
49 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) n
50 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) n
51 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) n
52 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) n
53 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) n
54 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) n
56 in ../sysdeps/x86_64/dl-trampoline.S
(gdb) n
boost::intrusive_ptr<geno_eye::Frame>::operator= (this=0x6071b0, rhs=0x3e8)
at /usr/include/boost/smart_ptr/intrusive_ptr.hpp:134
134 {
What is dl-trampoline.S ? Why it silently write on the memory of my object?
In addition of that, I also run valgrind:
$ valgrind ./t_page
However, instead of invalid write, it reports invalid read to that object, which is happened after the object creation is finished.
This is caused by an reference-to-stack bug.
Object genome_scale holds two references to two member variables of frame object. When I reconstruct my code, it accidentally reference to two stack variables...
So, maybe I should avoid the use of reference types in this situation, as you can easily provide stack stuffs to them and don't get any warns.
I get a SEGFAULT at the first line in the if-block, takeFirst().
if (!sendQueue.isEmpty()) {
QString nxtcmd = sendQueue.takeFirst();
port->write(nxtcmd.toLatin1());
port->flush();
}
I have code pushing 96 command strings into the queue with
if (completionHandlerQueue.empty()) {
…
} else {
sendQueue.append(cmd_str);
}
The latter happens in my main GUI code. The first bit is called by a signal by QExtSerialPort (when data is there to be read).
sendQueue is a member and declared as such:
class SB::ModuleCommunicator : public QObject
{
…
private:
…
QStringList sendQueue;
Now I'm not using threads and I assumed the Qt Event Loop would make everything work smoothly, but the full backtrace does tell me that there are in fact 3 threads.
According to documentation, Qt Containers are only thread-safe for read only access.
But the Queue is already full with all 96 strings when it crashes. So I don't think anything is appending while the list is being modified.
Is this a thread issue? How can I find out?
Here is the stacktrace:
0 _int_malloc malloc.c 3530 0x7ffff61c7410
1 __GI___libc_malloc malloc.c 2924 0x7ffff61c9f95
2 QListData::detach(int) /usr/lib/x86_64-linux-gnu/libQtCore.so.4 0 0x7ffff6cd397b
3 QList<QString>::detach_helper qlist.h 709 0x412169
4 QList<QString>::detach_helper qlist.h 725 0x411cf2
5 QList<QString>::detach qlist.h 139 0x411e72
6 QList<QString>::begin qlist.h 267 0x423610
7 QList<QString>::first qlist.h 282 0x422dda
8 QList<QString>::takeFirst qlist.h 490 0x422885
9 SB::ModuleCommunicator::handleMsg ModuleCommunicator.cpp 116 0x41f9be
10 SB::ModuleCommunicator::onReadyRead ModuleCommunicator.cpp 393 0x421f4d
11 SB::ModuleCommunicator::qt_static_metacall moc_ModuleCommunicator.cpp 52 0x435e1e
12 QMetaObject::activate(QObject*, QMetaObject const*, int, void**) /usr/lib/x86_64-linux-gnu/libQtCore.so.4 0 0x7ffff6dc9281
13 QextSerialPortPrivate::_q_canRead qextserialport.cpp 313 0x40c505
14 QextSerialPort::qt_static_metacall moc_qextserialport.cpp 97 0x40dbfa
15 QMetaObject::activate(QObject*, QMetaObject const*, int, void**) /usr/lib/x86_64-linux-gnu/libQtCore.so.4 0 0x7ffff6dc9281
16 QSocketNotifier::activated(int) /usr/lib/x86_64-linux-gnu/libQtCore.so.4 0 0x7ffff6e162fe
17 QSocketNotifier::event(QEvent*) /usr/lib/x86_64-linux-gnu/libQtCore.so.4 0 0x7ffff6dd260b
18 QApplicationPrivate::notify_helper(QObject*, QEvent*) /usr/lib/x86_64-linux-gnu/libQtGui.so.4 0 0x7ffff72d7894
19 QApplication::notify(QObject*, QEvent*) /usr/lib/x86_64-linux-gnu/libQtGui.so.4 0 0x7ffff72dc713
20 QCoreApplication::notifyInternal(QObject*, QEvent*) /usr/lib/x86_64-linux-gnu/libQtCore.so.4 0 0x7ffff6db4e9c
... <More>
UDPATE:
So it seems I have a transient error here. Now it crashed at
for (int i = 0; i < msgBuffer->size(); i++) {
with msgBuffer being yet another QStringList member of my Class. This piece of code is in the 'onReadyRead()' Slot that gets called when QExtSerialPort has data for me.
So I think the error is related to that package.
I'm using Qt 4.8 on Ubuntu 12.04 with QExtSerialPort v1.2rc from https://code.google.com/p/qextserialport
I'm getting a strange crash, manifesting itself as an EXC_BAD_ACCESS that always happens somewhere on the call stack of a thread opened by FMOD calling it's OpenCallback (the function that is called when FMOD can't find a sound in memory so needs to load it from the disk). The crash comes at a number of different places and I can't seem to find any reason why this changes, since the execution path is essentially the same. One thing I've noticed though is that there are two calls to the same non-recursive constructor adjacent to each other in the call stack. That is, the debugger (Xcode/LLDB, but I've tried it with Xcode/GDB) thinks that this constructor is calling itself, but it isn't.
Another thing I noticed is that the offsets for these calls are different, even though they're referring to the same function. Does anyone know what might be going on? I'm pretty stuck since I don't even know what this kind of problem is called (and therefore can't Google it).
Here's a call stack for one of the crashes (some things are renamed for anonymity, but I tried to keep the naming convention consistent). Notice that the CString and PIFilePath constructors are called twice each, adjacently.
* thread #49: tid = 0x6003, 0x009d3220 MyProject`SpinLock::Lock() + 64 at spinlock.h:73, stop reason = EXC_BAD_ACCESS (code=2, address=0xb01f7ffc)
frame #0: 0x009d3220 MyProject`SpinLock::Lock() + 64 at spinlock.h:73
frame #1: 0x0099d8e0 MyProject`tcmalloc::CentralFreeList::RemoveRange(void**, void**, int) + 160 at central_freelist.cc:211
frame #2: 0x009b4989 MyProject`tcmalloc::ThreadCache::FetchFromCentralCache(unsigned long, unsigned long) + 281 at thread_cache.cc:149
frame #3: 0x009d66fc MyProject`tcmalloc::ThreadCache::Allocate(unsigned long, unsigned long) + 332 at thread_cache.h:330
frame #4: 0x009ce123 MyProject`do_malloc + 227 at tcmalloc.cc:960
frame #5: 0x009ce1e5 MyProject`do_malloc_or_cpp_alloc + 85 at tcmalloc.cc:897
frame #6: 0x009d1285 MyProject`MallocBlock::Allocate(unsigned long, int) + 517 at debugallocation.cc:534
frame #7: 0x009ce460 MyProject`DebugAllocate + 48 at debugallocation.cc:968
frame #8: 0x011cc942 MyProject`malloc + 50
frame #9: 0x00a80bbf MyProject`CSystemUtilities::CSAllocate(long, unsigned long, void*) + 47 at CSystemUtilities.cpp:2358
frame #10: 0x96a08d17 CoreFoundation`CFAllocatorAllocate + 343
frame #11: 0x96a0de4b CoreFoundation`__CFStringChangeSizeMultiple + 1179
frame #12: 0x96a219d6 CoreFoundation`CFStringCreateMutableCopy + 454
frame #13: 0x00a9bae2 MyProject`CString::SetCFString(__CFString const*, bool) + 114 at CString.cpp:527
frame #14: 0x00a9bcb0 MyProject`CString::CString(CString const&) + 112 at CString.cpp:189
frame #15: 0x00a9bc1f MyProject`CString::CString(CString const&) + 47 at CString.cpp:190
frame #16: 0x00aa3a9e MyProject`PIFilePath::NormalisePath(CString const&, long, bool, unsigned short) + 2142 at PIFilePath.cpp:2021
frame #17: 0x00aa2dc9 MyProject`PIFilePath::FindPathInList(CString const&, std::vector<CString, std::allocator<CString> > const&) + 89 at PIFilePath.cpp:1716
frame #18: 0x00aa3d26 MyProject`PIFilePath::IsAbsolutePath(CString const&) + 134 at PIFilePath.cpp:465
frame #19: 0x00aa62d1 MyProject`PIFilePath::ApplyMappingsToPath(CString const&, CString const&, bool) + 1041 at PIFilePath.cpp:1323
frame #20: 0x00aa292d MyProject`PIFilePath::TranslatePath(CString const&) const + 4157 at PIFilePath.cpp:1645
frame #21: 0x00aa15ad MyProject`PIFilePath::SetPath(CString const&, PIFilePath::ConvertPathMode) + 253 at PIFilePath.cpp:175
frame #22: 0x00aa1460 MyProject`PIFilePath::PIFilePath(CString const&, PIFilePath::ConvertPathMode) + 96 at PIFilePath.cpp:122
frame #23: 0x00aa13dd MyProject`PIFilePath::PIFilePath(CString const&, PIFilePath::ConvertPathMode) + 61 at PIFilePath.cpp:123
frame #24: 0x00becad8 MyProject`FileAttributes + 88 at pi_files.cpp:3341
frame #25: 0x0090702b MyProject`SystemStuff::CWinFS::Exists(char const*) + 219 at fsWin.cpp:627
frame #26: 0x008e2892 MyProject`SystemStuff::CMultiFS::FindFS(char const*) + 162 at fsMulti.cpp:390
frame #27: 0x008e1466 MyProject`SystemStuff::CMultiFS::Open(SystemStuff::RCPtr<SystemStuff::IBlock>&, char const*, unsigned long) + 134 at fsMulti.cpp:223
frame #28: 0x008db911 MyProject`SystemStuff::CDispatchFS::Open(SystemStuff::RCPtr<SystemStuff::IBlock>&, char const*, unsigned long) + 321 at fsDispatch.cpp:158
frame #29: 0x008cbb89 MyProject`SystemStuff::FS::Open(SystemStuff::RCPtr<SystemStuff::IBlock>&, char const*, unsigned long) + 233 at fs.cpp:135
frame #30: 0x00985611 MyProject`OpenCallback(char const*, int, unsigned int*, void**, void**) + 177 at sndFMODEx.cpp:324
frame #31: 0x029ecf59 libfmodex.dylib`FMOD::DSP::disconnectFrom(FMOD::DSP*) + 25999
frame #32: 0x029ee7cb libfmodex.dylib`FMOD_File_SetDiskBusy + 4861
frame #33: 0x02a0c15b libfmodex.dylib`FMOD::SystemI::createSoundInternal(char const*, unsigned int, unsigned int, unsigned int, FMOD_CREATESOUNDEXINFO*, FMOD::File**, bool, FMOD::SoundI**) + 2413
frame #34: 0x0298b6aa libfmodex.dylib
frame #35: 0x02a11d2c libfmodex.dylib`FMOD::SystemI::createSoundInternal(char const*, unsigned int, unsigned int, unsigned int, FMOD_CREATESOUNDEXINFO*, FMOD::File**, bool, FMOD::SoundI**) + 25918
frame #36: 0x91b6d557 libsystem_c.dylib`_pthread_start + 344
This is the crash I get about 40% of the time, and the other 60% of the time it fails at NormalisePath (but the callstack above that is the same).