I'm trying to read the content of a file (containing only integers) into a 2D table, but I get the segmentation fault error at the close statement.
vector<vector<int>> litTableauInt(string nom_fichier, int nb_colonnes) {
int n;
int i=0;
vector<int> colonne(nb_colonnes);
vector<vector<int>> t(nb_colonnes,vector<int>(1));
ifstream fichier(nom_fichier);
while(fichier>>n){
t[i][0]=n;
for(int j=1; j<nb_colonnes; j++){
fichier>>n;
t[i][j]=n;
}
t.push_back(colonne);
i++;
}
fichier.close();
return t;
}
I located the error using the gbd command (file file_name, run, bt)
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff74dac01 in __GI___libc_free (mem=0x55555576f1f0) at malloc.c:3123
(gdb) bt
#0 0x00007ffff74dac01 in __GI___libc_free (mem=0x55555576f1f0) at malloc.c:3123
#1 0x00007ffff74c12fe in _IO_new_fclose (fp=0x55555576f1f0) at iofclose.c:77
#2 0x00007ffff7affd98 in std::__basic_file<char>::close() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff7b3f75b in std::basic_filebuf<char, std::char_traits<char> >::close() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff7b418a5 in std::basic_ifstream<char, std::char_traits<char> >::~basic_ifstream() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00005555555554ef in litTableauInt (nom_fichier="donnees/tonnages_des_dechets_bacs_jaunes.txt", nb_colonnes=13) at dechets-tableau.cpp:24
#6 0x0000555555555614 in testLitTableauInt () at dechets-tableau.cpp:42
#7 0x0000555555556178 in main () at dechets-tableau.cpp:96
Thank you #Some programmer dude
You put me on the right track, I had inverted the lines and columns when I declared my 2D table (line 5),it should have been :
vector<vector<int>> t(1,vector<int>(nb_colonnes));
Related
I have a code snippet that is behaving weirdly. The code is simply aiming to implement radix and bucket sort. When I comment in the main one of either sort and run it works perfectly. But when I enable both of them i am getting a core dump. And the weird part is core dump as indicated by the stack is crossing over into the stl_vector.h.
The code reference is here:- https://rextester.com/RUUDP10453
When i enable only one of the sorts like below in main it works fine.
//doRadixSort(arr, size);
doBucketSort(arr, size);
or
doRadixSort(arr, size);
//doBucketSort(arr, size);
But when both are enabled there is segmentation fault after both sorts are completed as indicated by the
cout << "i am here at exit" << endl;
The core dump stack indicates some reference/hint at vector of vector buckets. But i have properly allocated and reserved it the required memory. so why this is happening i need some expertise to dig out. I have tried debugging this in eclipse CDT C++ for about 2 hrs with no lead.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 _int_free (av=0x7f66d702eb00 <main_arena>, p=0xf98020, have_lock=0) at malloc.c:3976
3976 >= ((char *) av->top + chunksize(av->top)), 0))
(gdb) where
#0 _int_free (av=0x7f66d702eb00 <main_arena>, p=0xf98020, have_lock=0) at malloc.c:3976
#1 0x00007f66d6cf33dc in __GI___libc_free (mem=<optimized out>) at malloc.c:2966
#2 0x00000000004030fa in __gnu_cxx::new_allocator<std::vector<int, std::allocator<int> > >::deallocate (this=0x7fffc6ffa060, __p=0xf98030) at /usr/include/c++/6.3.1/ext/new_allocator.h:110
#3 0x0000000000402d23 in std::allocator_traits<std::allocator<std::vector<int, std::allocator<int> > > >::deallocate (__a=..., __p=0xf98030, __n=10) at /usr/include/c++/6.3.1/bits/alloc_traits.h:442
#4 0x00000000004027ac in std::_Vector_base<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > >::_M_deallocate (this=0x7fffc6ffa060, __p=0xf98030, __n=10)
at /usr/include/c++/6.3.1/bits/stl_vector.h:178
#5 0x00000000004025e4 in std::_Vector_base<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > >::~_Vector_base (this=0x7fffc6ffa060, __in_chrg=<optimized out>)
at /usr/include/c++/6.3.1/bits/stl_vector.h:160
#6 0x000000000040211d in std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > >::~vector (this=0x7fffc6ffa060, __in_chrg=<optimized out>)
at /usr/include/c++/6.3.1/bits/stl_vector.h:427
#7 0x0000000000401d4b in doBucketSort (arr=0x7fffc6ffa100, size=#0x7fffc6ffa0f8: 12) at tako.cpp:97
#8 0x0000000000401e29 in main (argc=1, argv=0x7fffc6ffa218) at tako.cpp:141
(gdb)
Alternatively, I found the below also works which is equivalent to the resize function.
vector<vector<int>> buckets;
constexpr size_t size=10, bucketSize=10;
buckets.reserve(bucketSize);
for(unsigned int i=0; i<=bucketSize; ++i)
buckets.push_back({ });
for(unsigned int i=0; i<=bucketSize; ++i)
buckets[i].reserve(size);
I've boiled this down to a simple self-contained example. The main thread enqueues 1000 items, and a worker thread tries to dequeue concurrently. ThreadSanitizer complains that there's a race between the read and the write of one of the elements, even though there is an acquire-release memory barrier sequence protecting them.
#include <atomic>
#include <thread>
#include <cassert>
struct FakeQueue
{
int items[1000];
std::atomic<int> m_enqueueIndex;
int m_dequeueIndex;
FakeQueue() : m_enqueueIndex(0), m_dequeueIndex(0) { }
void enqueue(int x)
{
auto tail = m_enqueueIndex.load(std::memory_order_relaxed);
items[tail] = x; // <- element written
m_enqueueIndex.store(tail + 1, std::memory_order_release);
}
bool try_dequeue(int& x)
{
auto tail = m_enqueueIndex.load(std::memory_order_acquire);
assert(tail >= m_dequeueIndex);
if (tail == m_dequeueIndex)
return false;
x = items[m_dequeueIndex]; // <- element read -- tsan says race!
++m_dequeueIndex;
return true;
}
};
FakeQueue q;
int main()
{
std::thread th([&]() {
int x;
for (int i = 0; i != 1000; ++i)
q.try_dequeue(x);
});
for (int i = 0; i != 1000; ++i)
q.enqueue(i);
th.join();
}
ThreadSanitizer output:
==================
WARNING: ThreadSanitizer: data race (pid=17220)
Read of size 4 at 0x0000006051c0 by thread T1:
#0 FakeQueue::try_dequeue(int&) /home/cameron/projects/concurrentqueue/tests/tsan/issue49.cpp:26 (issue49+0x000000402bcd)
#1 main::{lambda()#1}::operator()() const <null> (issue49+0x000000401132)
#2 _M_invoke<> /usr/include/c++/5.3.1/functional:1531 (issue49+0x0000004025e3)
#3 operator() /usr/include/c++/5.3.1/functional:1520 (issue49+0x0000004024ed)
#4 _M_run /usr/include/c++/5.3.1/thread:115 (issue49+0x00000040244d)
#5 <null> <null> (libstdc++.so.6+0x0000000b8f2f)
Previous write of size 4 at 0x0000006051c0 by main thread:
#0 FakeQueue::enqueue(int) /home/cameron/projects/concurrentqueue/tests/tsan/issue49.cpp:16 (issue49+0x000000402a90)
#1 main /home/cameron/projects/concurrentqueue/tests/tsan/issue49.cpp:44 (issue49+0x000000401187)
Location is global 'q' of size 4008 at 0x0000006051c0 (issue49+0x0000006051c0)
Thread T1 (tid=17222, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x000000027a67)
#1 std::thread::_M_start_thread(std::shared_ptr<std::thread::_Impl_base>, void (*)()) <null> (libstdc++.so.6+0x0000000b9072)
#2 main /home/cameron/projects/concurrentqueue/tests/tsan/issue49.cpp:41 (issue49+0x000000401168)
SUMMARY: ThreadSanitizer: data race /home/cameron/projects/concurrentqueue/tests/tsan/issue49.cpp:26 FakeQueue::try_dequeue(int&)
==================
ThreadSanitizer: reported 1 warnings
Command line:
g++ -std=c++11 -O0 -g -fsanitize=thread issue49.cpp -o issue49 -pthread
g++ version: 5.3.1
Can anybody shed some light onto why tsan thinks this is a data race?
UPDATE
It seems like this is a false positive. To appease ThreadSanitizer, I've added annotations (see here for the supported ones and here for an example). Note that detecting whether tsan is enabled in GCC via a macro has only recently been added, so I had to manually pass -D__SANITIZE_THREAD__ to g++ for now.
#if defined(__SANITIZE_THREAD__)
#define TSAN_ENABLED
#elif defined(__has_feature)
#if __has_feature(thread_sanitizer)
#define TSAN_ENABLED
#endif
#endif
#ifdef TSAN_ENABLED
#define TSAN_ANNOTATE_HAPPENS_BEFORE(addr) \
AnnotateHappensBefore(__FILE__, __LINE__, (void*)(addr))
#define TSAN_ANNOTATE_HAPPENS_AFTER(addr) \
AnnotateHappensAfter(__FILE__, __LINE__, (void*)(addr))
extern "C" void AnnotateHappensBefore(const char* f, int l, void* addr);
extern "C" void AnnotateHappensAfter(const char* f, int l, void* addr);
#else
#define TSAN_ANNOTATE_HAPPENS_BEFORE(addr)
#define TSAN_ANNOTATE_HAPPENS_AFTER(addr)
#endif
struct FakeQueue
{
int items[1000];
std::atomic<int> m_enqueueIndex;
int m_dequeueIndex;
FakeQueue() : m_enqueueIndex(0), m_dequeueIndex(0) { }
void enqueue(int x)
{
auto tail = m_enqueueIndex.load(std::memory_order_relaxed);
items[tail] = x;
TSAN_ANNOTATE_HAPPENS_BEFORE(&items[tail]);
m_enqueueIndex.store(tail + 1, std::memory_order_release);
}
bool try_dequeue(int& x)
{
auto tail = m_enqueueIndex.load(std::memory_order_acquire);
assert(tail >= m_dequeueIndex);
if (tail == m_dequeueIndex)
return false;
TSAN_ANNOTATE_HAPPENS_AFTER(&items[m_dequeueIndex]);
x = items[m_dequeueIndex];
++m_dequeueIndex;
return true;
}
};
// main() is as before
Now ThreadSanitizer is happy at runtime.
This looks like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158. Disassembling the binary produced by GCC shows that it doesn't instrument the atomic operations on O0.
As a workaround, you can either build your code with GCC with -O1/-O2, or get yourself a fresh Clang build and use it to run ThreadSanitizer (this is the recommended way, as TSan is being developed as part of Clang and only backported to GCC).
The comments above are invalid: TSan can easily comprehend the happens-before relation between the atomics in your code (one can check that by running the above reproducer under TSan in Clang).
I also wouldn't recommend using the AnnotateHappensBefore()/AnnotateHappensAfter() for two reasons:
you shouldn't need them in most cases; they denote that the code is doing something really complex (in which case you may want to double-check you're doing it right);
if you make an error in your lock-free code, spraying it with annotations may mask that error, so that TSan won't notice it.
The ThreadSanitizer is not good at counting, it cannot understand that writes to the items always happen before the reads.
The ThreadSanitizer can find that the stores of m_enqueueIndex happen before the loads, but it does not understand that the store to items[m_dequeueIndex] must happen before the load when tail > m_dequeueIndex.
After adding boost syslog into source code, segmentation fault appears inside cpp-netlib library.
I was able to prepare minimum working code snippet to reproduce the problem.
#include <boost/network/protocol/http/client.hpp>
#include <boost/log/utility/setup/file.hpp>
#include <boost/log/sinks/syslog_backend.hpp>
#include <iostream>
using namespace boost::network;
using namespace boost::network::http;
namespace sinks = boost::log::sinks;
int main()
{
client::request request_("http://www.boost.org/");
client client_;
client::response response_ = client_.get(request_);
std::string body_ = body(response_);
std::cout << "body: " << body_;
using syslog_sinkT = sinks::synchronous_sink <sinks::syslog_backend>;
boost::shared_ptr <sinks::syslog_backend> backend = boost::make_shared <sinks::syslog_backend> ();
boost::shared_ptr<syslog_sinkT> sink = boost::make_shared <syslog_sinkT> (backend);
}
When last 2 lines are commented, segmentation fault disappears and everything works fine.
gdb stack trace (approximately, may vary):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf7c29b40 (LWP 19874)]
0x00000000 in ?? ()
(gdb) where
#0 0x00000000 in ?? ()
#1 0x083c376c in boost::asio::detail::task_io_service_operation::complete (bytes_transferred=260, ec=..., owner=...,
this=0xf6900710)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/asio/detail/task_io_service_o$
eration.hpp:38
#2 boost::asio::detail::task_io_service::do_run_one (ec=..., this_thread=..., lock=..., this=<optimized out>)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/asio/detail/impl/task_io_serv$
ce.ipp:372
#3 boost::asio::detail::task_io_service::run (ec=..., this=0x84ea280)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/asio/detail/impl/task_io_serv$
ce.ipp:149
#4 boost::asio::io_service::run (this=0x84e9a94)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/asio/impl/io_service.ipp:59
#5 0x083b5766 in boost::_mfi::mf0<unsigned int, boost::asio::io_service>::operator() (p=<optimized out>, this=<optimized out>)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/bind/mem_fn_template.hpp:49
#6 boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> >::operator()<unsigned int, boost::_mfi::mf0<unsigned int, boost::a$
io::io_service>, boost::_bi::list0> (a=<synthetic pointer>, f=..., this=0x84ea94c)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/bind/bind.hpp:249
#7 boost::_bi::bind_t<unsigned int, boost::_mfi::mf0<unsigned int, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boo$
t::asio::io_service*> > >::operator() (this=0x84ea944)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/bind/bind.hpp:1222
#8 boost::detail::thread_data<boost::_bi::bind_t<unsigned int, boost::_mfi::mf0<unsigned int, boost::asio::io_service>, boost::_bi::$
ist1<boost::_bi::value<boost::asio::io_service*> > > >::run (this=0x84ea828)
at /home/kostidov/prj/third_party-master/boost/boost_1_60_0/__public__/v0/Linux-libc6/include/boost/thread/detail/thread.hpp:116
#9 0x0840a4f8 in boost::(anonymous namespace)::thread_proxy (param=0x84ea828) at libs/thread/src/pthread/thread.cpp:167
#10 0xf7de1f70 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#11 0xf7d18bee in clone () from /lib/i386-linux-gnu/libc.so.6
Problem exists on Ubuntu 14.04 with cpp-netlib 0.11.2 and both boost versions 1_58_0 and 1_60_0. Boost, cpp-netlib and my application are compiled with -std=c++11.
Note 1. Segmentation fault appears inside cpp-netlib before reaching syslog_backend creation. Only presence of last 2 lines guarantees SIGSEGV reproduction.
Note 2. Reproduces only with syslog_backend. Any other logging targets (file, consol) work fine.
The best idea I have is the problem may lay inside boost during static variables initialisation, but I have no proves regarding this version.
Any suggestions?
Seems like I used too many compile options for building both boost and cpp-netlib.
I prepared new build for both boost and cpp-netlib once again, but this time I used as less additional options as possible.
And it works fine.
EDIT: I found the key which causes the error. It's BOOST_ASIO_ENABLE_HANDLER_TRACKING It was defined during the boost compilation, but wasn't defined during compilation of cpp-netlib and my application.
https://svn.boost.org/trac/boost/ticket/11945
My distribution (Debian) ships debug files in separate packages. So what happens often is that I run a program in gdb until it crashes, in order to obtain a usable backtrace for a bug report. But bt is rather useless, missing the symbol information – because I did not install the corresponding -dbg package.
If I install the package now, is there a way to make gdb search for the symbol files again, without losing my current backtrace?
There is a trick you can use to make gdb try to read symbol files again:
(gdb) nosharedlibrary
(gdb) sharedlibrary
The first command tells it to forget all the symbol information it has, and the second command tells it to re-read it.
I am going to suggest an alternative approach with gdb gcore command, possibly it is suitable for you.
This is gcore description:
(gdb) help gcore
Save a core file with the current state of the debugged process.
Argument is optional filename. Default filename is 'core.<process_id>'
So I have a program that causes a crash:
include <iostream>
int f()
{
time_t curr_ts = time(0);
std::cout << "Before crash " << curr_ts << std::endl;
int * ptr = 0;
*ptr = *ptr +1 ;
std::cout << "After crash " << curr_ts << std::endl;
return *ptr;
}
int main()
{
std::cout << "Before f() " << std::endl;
f();
std::cout << "After f() " << std::endl;
return 0;
}
I compiled it with debug info. However I put the executable with debug info in an archive and for tests use a stripped version.
So it crashes under gdb:
$ gdb ./a.out
Reading symbols from ./a.out...(no debugging symbols found)...done.
(gdb) r
Starting program: /home/crash/a.out
Before f()
Before crash 1435322344
Program received signal SIGSEGV, Segmentation fault.
0x000000000040097d in ?? ()
(gdb) bt
#0 0x000000000040097d in ?? ()
#1 0x00000000004009e0 in ?? ()
#2 0x000000314981ed1d in __libc_start_main () from /lib64/libc.so.6
#3 0x00000000004007f9 in ?? ()
#4 0x00007fffffffde58 in ?? ()
#5 0x000000000000001c in ?? ()
#6 0x0000000000000001 in ?? ()
#7 0x00007fffffffe1a9 in ?? ()
#8 0x0000000000000000 in ?? ()
(gdb) gcore crash2.core
Saved corefile crash2.core
I simply generate core file with gcore and leave gdb. Then I get from the archive the version with debug symbols and I can see all symbols:
$ gdb ./a.out ./crash2.core
Reading symbols from ./a.out...done.
warning: exec file is newer than core file.
[New LWP 15215]
Core was generated by `/home/crash/a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000040097d in f () at main.cpp:8
8 *ptr = *ptr +1 ;
(gdb) bt
#0 0x000000000040097d in f () at main.cpp:8
#1 0x00000000004009e0 in main () at main.cpp:17
(gdb) info locals
curr_ts = 1435322344
ptr = 0x0
Update
if you set backtrace past-main on you will see at least this __libc_start_main. What is above __libc_start_main is not printed if you analyze only core file (possibly even not saved there) saved wit gcore:
$ gdb ./a.out crash2.core
Reading symbols from ./a.out...done.
warning: exec file is newer than core file.
[New LWP 15215]
Core was generated by `/home/crash/a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000040097d in f () at main.cpp:8
8 *ptr = *ptr +1 ;
(gdb) set backtrace past-main on
(gdb) bt
#0 0x000000000040097d in f () at main.cpp:8
#1 0x00000000004009e0 in main () at main.cpp:17
#2 0x000000314981ed1d in __libc_start_main () from /lib64/libc.so.6
Backtrace stopped: Cannot access memory at address 0x4007d0
(gdb)
But if I reproduce the crash under gdb with my test program (with debug info in it) I can see all (see set backtrace past-main on && set backtrace past-entry on):
$ gdb ./a.out
Reading symbols from ./a.out...done.
(gdb) r
Starting program: /home/crash/a.out
Before f()
Before crash 1435328858
Program received signal SIGSEGV, Segmentation fault.
0x000000000040097d in f () at main.cpp:8
8 *ptr = *ptr +1 ;
(gdb) bt
#0 0x000000000040097d in f () at main.cpp:8
#1 0x00000000004009e0 in main () at main.cpp:17
(gdb) set backtrace past-main on
(gdb) set backtrace past-entry on
(gdb) bt
#0 0x000000000040097d in f () at main.cpp:8
#1 0x00000000004009e0 in main () at main.cpp:17
#2 0x000000314981ed1d in __libc_start_main () from /lib64/libc.so.6
#3 0x00000000004007f9 in _start ()
#4 0x00007fffffffde58 in ?? ()
#5 0x000000000000001c in ?? ()
#6 0x0000000000000001 in ?? ()
#7 0x00007fffffffe1a9 in ?? ()
#8 0x0000000000000000 in ?? ()
(gdb)
I am noticing a strange problem when I attempt to use the signal handler to dump global data to a text file and generate the core file. I would expect the data dumped to the file to be the same as that is present in the core file (it is the same global data)
in a header file foo.h
extern char buffer[100][80] ; // Hundred records each of length 80 characters
in foo.c
char buffer[100][80];
.. in a loop ..
snprintf(buffer[i],80,"%s:%d recorded idx = %d\n",__FUNCTION__,__LINE__,i);
in signal_handler.c
.. in a loop ..
fprintf(..dump data to text file..)
The data is dumped to the text file alright. I run the program in gdb and I issue the ABRT signal (the signal I am handling) via kill. In gdb I see
gdb) p &buffer[0]
$3 = (char (*)[80]) 0x1002c8970
I continue and generate the core file. In the core dump I see
(gdb) p &buffer[0]
$2 = (char (*)[80]) 0x1002c9a80
the difference between the two positions is 1110.
My question is why do I see this discrepancy in the core file ? Any leads would be appreciated!
Thanks
John
EDIT To clarify, the problem is not in generating the core via GDB
Full code without signal handlers to isolate the problem.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define MAX 100
char buffer[100][80];
int main()
{
int i = 0;
int idx = 0;
FILE *fp = NULL;
fp = fopen("test.txt","w");
if (!fp)
exit(1);
for (i=0; i < 5500; i++) {
snprintf(buffer[idx],80,"%s:%d idx = %d\n",__FUNCTION__, __LINE__, i);
idx = ((idx + 1)% MAX);
}
for (i = 0 ; i < MAX; i++)
fprintf(fp,"%s",buffer[i]);
fclose(fp);
abort();
return 0;
}
The problem is not when I am trying to run in GDB, the problem is that in the core file generated,
gdb) p buffer[0]
$2 "c0 - idx = 54\n", '\0' , "main:20 0x7ef9524"
the buffer is offset by 1110 bytes. I had used GDB to check if the buffer was corrupted. Sorry about the confusion.
Please provide a stand-alone example. I can explain different address when the core is produced from outside GDB, but not when it is produced from inside GDB.
Here is what I see:
$ cat foo.c
#include <stdio.h>
#include <stdlib.h>
char buf[100][80];
int main()
{
sprintf(buf[0], "hello");
sprintf(buf[1], "hello again");
abort();
}
$ gcc -g foo.c -fPIC -pie # PIE executable so its address can be randomized
$ gdb -q a.out
Reading symbols from /tmp/a.out...done.
(gdb) r
Program received signal SIGABRT, Aborted.
0x00007ffff7a8ca75 in raise () at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
(gdb) p &buf[0]
$1 = (char (*)[80]) 0x7ffff81ff060
(gdb) sig SIGABRT
Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
(gdb) q
$ gdb -q a.out core
Reading symbols from /tmp/a.out...done.
[New Thread 20440]
Core was generated by `/tmp/a.out'.
Program terminated with signal 6, Aborted.
#0 0x00007ffff7a8ca75 in raise () at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
(gdb) p &buf[0]
$1 = (char (*)[80]) 0x7ffff81ff060 # same address as before
(gdb) q
$ ./a.out
Aborted (core dumped)
$ gdb -q a.out core
Reading symbols from /tmp/a.out...done.
[New Thread 20448]
Core was generated by `./a.out'.
Program terminated with signal 6, Aborted.
#0 0x00007fef9dcb5a75 in raise () at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
(gdb) p &buf[0]
$1 = (char (*)[80]) 0x7fef9e428060 # different address due to ASLR