stack smash error occured in using a staic library - gcc

i developed a static library, and a test application to call its
functions.
Now, when i am executing the test application, it was able to get in to
the function and calculate the required values, but when the return is
called it is giving stack smash error
./test_app
USB Handle opened SUCCESSFULLY
*** stack smashing detected ***: /home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7ffff7b25807]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x7ffff7b257d0]
/home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app[0x4008ec]
/home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app[0x4006ed]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7ffff7a3c76d]
/home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app[0x400619]
======= Memory map: ========
00400000-00402000 r-xp 00000000 08:08 1186 /home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app
00601000-00602000 r--p 00001000 08:08 1186 /home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app
00602000-00603000 rw-p 00002000 08:08 1186 /home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app
00603000-00624000 rw-p 00000000 00:00 0 [heap]
7ffff7805000-7ffff781a000 r-xp 00000000 08:05 658720 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff781a000-7ffff7a19000 ---p 00015000 08:05 658720 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7a19000-7ffff7a1a000 r--p 00014000 08:05 658720 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7a1a000-7ffff7a1b000 rw-p 00015000 08:05 658720 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7a1b000-7ffff7bd0000 r-xp 00000000 08:05 658699 /lib/x86_64-linux-gnu/libc-2.15.so
7ffff7bd0000-7ffff7dcf000 ---p 001b5000 08:05 658699 /lib/x86_64-linux-gnu/libc-2.15.so
7ffff7dcf000-7ffff7dd3000 r--p 001b4000 08:05 658699 /lib/x86_64-linux-gnu/libc-2.15.so
7ffff7dd3000-7ffff7dd5000 rw-p 001b8000 08:05 658699 /lib/x86_64-linux-gnu/libc-2.15.so
7ffff7dd5000-7ffff7dda000 rw-p 00000000 00:00 0
7ffff7dda000-7ffff7dfc000 r-xp 00000000 08:05 658679 /lib/x86_64-linux-gnu/ld-2.15.so
7ffff7fdd000-7ffff7fe0000 rw-p 00000000 00:00 0
7ffff7ff6000-7ffff7ffb000 rw-p 00000000 00:00 0
7ffff7ffb000-7ffff7ffc000 r-xp 00000000 00:00 0 [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 00022000 08:05 658679 /lib/x86_64-linux-gnu/ld-2.15.so
7ffff7ffd000-7ffff7fff000 rw-p 00023000 08:05 658679 /lib/x86_64-linux-gnu/ld-2.15.so
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Here is the test application
#include <stdio.h>
#include "leapfrog.h"
void main()
{
unsigned int mid=0x0;
USB_Init();
mid = Read_MID();
printf("\n mid = 0x%x\n",mid);
USB_Deinit();
return;
}
The above was the test application and it was referencing this function in the library
uint16 Read_MID(void)
{
int8 buf[8]={0};
uint16 mid;
//Read Vendor id
buf[0] = 0xFE;
msp_write(0x41,buf,1);
msp_read(0x41,buf,2);
mid = buf[0];
mid <<= 8;
mid |= buf[1];
return mid;
}
till the "mid" calculation i could get the correct values. it is reaching till the end while debugging with insight debugger. just after "}" in the console i see the stack smash error.
what might be the cause of the stack smash.
Thank you for time and patience.

I resolved it by adding more array space.
int8 buf[8]={0};
i made it as
int8 buf[10]={0};

Related

Ruby 2.5.1 crashed - how to read this memory map?

I'm upgrading to Ruby 2.5.1 and when a unicorn worker crashed during testing, I got a ton of output that I'm not sure how to interpret.
Does anyone know what each of these columns means? I think if I understood this better, I'd be able to find what caused the issue, as the output is rather larger than what I pasted here.
* Process memory map:
55d388ebb000-55d3891db000 r-xp 00000000 ca:01 4623622 /opt/ruby-2.5.1/bin/ruby
55d3893db000-55d3893e0000 r--p 00320000 ca:01 4623622 /opt/ruby-2.5.1/bin/ruby
55d3893e0000-55d3893e1000 rw-p 00325000 ca:01 4623622 /opt/ruby-2.5.1/bin/ruby
55d3893e1000-55d3893f2000 rw-p 00000000 00:00 0
55d38b066000-55d38bdf9000 rw-p 00000000 00:00 0 [heap]
55d38bdf9000-55d38d1a9000 rw-p 00000000 00:00 0 [heap]
55d38d1a9000-55d3a1258000 rw-p 00000000 00:00 0 [heap]
7f1bcc000000-7f1bcc021000 rw-p 00000000 00:00 0
7f1bcc021000-7f1bd0000000 ---p 00000000 00:00 0
7f1bd0e68000-7f1bd1031000 r--s 00000000 ca:01 13016
/lib/x86_64-linux-gnu/libc-2.23.so
....

STXXL fails at creating a map of strings in long numeric

With the code that follows, I want to create a map of type std::map. By using a debugger, I got that the exception was raised by stl_pair.h at line 368 (pair& operator=(typename conditional<__and_<is_copy_assignable<_T1>, is_copy_assignable<_T2>>::value, const pair&, const __wrap_nonesuch&>::type __p)), which was invoked by the map scanning of cur (*(cur + 1) = *cur;) in the leaf.h insert function of stxxl. I provide the code I used in the following source code:
#include <stxxl/map>
#include <fstream>
#include <string>
#include <cstdint>
typedef uint_fast64_t LONG_NUMERIC;
std::string random_string( size_t length )
{
auto randchar = []() -> char
{
const char charset[] =
"0123456789"
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"abcdefghijklmnopqrstuvwxyz";
const size_t max_index = (sizeof(charset) - 1);
return charset[ rand() % max_index ];
};
std::string str(length,0);
std::generate_n( str.begin(), length, randchar );
return str;
}
struct CompareGreater22
{
bool operator () (const std::string& a, const std::string& b) const
{ return a > b; }
static std::string max_value()
{ return std::string(); }
};
int main(int argc, char** argv) {
stxxl::config * cfg = stxxl::config::get_instance();
stxxl::disk_config disk1("/mnt/DEC4763AC47614CD/stxxl.tmp", 100 * 1024 * 1024, "syscall unlink");
disk1.direct = stxxl::disk_config::DIRECT_ON; // force O_DIRECT
// add disk to config
cfg->add_disk(disk1);
// template parameter <KeyType, DataType, CompareType, RawNodeSize, RawLeafSize, PDAllocStrategy (optional)>
typedef stxxl::map<std::string, LONG_NUMERIC, CompareGreater22, DATA_NODE_BLOCK_SIZE, DATA_LEAF_BLOCK_SIZE> map_type3;
// Constructor map(node_cache_size_in_bytes, leaf_cache_size_in_bytes)
map_type3 t((map_type3::node_block_type::raw_size)*3, (map_type3::leaf_block_type::raw_size)*3);
//vertex_conversion_map_type t{(vertex_conversion_map_type::node_block_type::raw_size)*3, (vertex_conversion_map_type::leaf_block_type::raw_size)*3};
for (LONG_NUMERIC i = 0; i< 2000; i++) {
t.insert(std::make_pair(random_string(10), i));
}
}
I also provide the dump result:
[STXXL-MSG] STXXL v1.4.99 (prerelease/Debug) (git 0a80a8c55993948f7f2f6c2c5a51ff45b403045b) + gnu parallel(20170406)
[STXXL-MSG] Disk '/mnt/DEC4763AC47614CD/stxxl.tmp' is allocated, space: 100 MiB, I/O implementation: syscall direct=on queue=0 devid=0 unlink_on_open
*** Error in `/anon/software/path': free(): invalid pointer: 0x000055c0cd7688d0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7908b)[0x7fd69ff1108b]
/lib/x86_64-linux-gnu/libc.so.6(+0x82c3a)[0x7fd69ff1ac3a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fd69ff1ed2c]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_assignERKS4_+0xaf)[0x7fd6a0ad0fcf]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSERKS4_+0x9)[0x7fd6a0ad1339]
/anon/software/path(+0x19bfb)[0x55c0cc841bfb]
/anon/software/path(+0x15699)[0x55c0cc83d699]
/anon/software/path(+0x10dba)[0x55c0cc838dba]
/anon/software/path(+0xf6fc)[0x55c0cc8376fc]
/anon/software/path(+0xd46d)[0x55c0cc83546d]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fd69feb83f1]
/anon/software/path(+0xd01a)[0x55c0cc83501a]
======= Memory map: ========
55c0cc828000-55c0cc9d8000 r-xp 00000000 08:02 509986 /anon/software/path
55c0ccbd7000-55c0ccbdc000 r--p 001af000 08:02 509986 /anon/software/path
55c0ccbdc000-55c0ccbdd000 rw-p 001b4000 08:02 509986 /anon/software/path
55c0ccbdd000-55c0ccbdf000 rw-p 00000000 00:00 0
55c0cd74a000-55c0cd78c000 rw-p 00000000 00:00 0 [heap]
7fd698000000-7fd698021000 rw-p 00000000 00:00 0
7fd698021000-7fd69c000000 ---p 00000000 00:00 0
7fd69f697000-7fd69f698000 ---p 00000000 00:00 0
7fd69f698000-7fd69fe98000 rw-p 00000000 00:00 0
7fd69fe98000-7fd6a0056000 r-xp 00000000 103:05 795936 /lib/x86_64-linux-gnu/libc-2.24.so
7fd6a0056000-7fd6a0255000 ---p 001be000 103:05 795936 /lib/x86_64-linux-gnu/libc-2.24.so
7fd6a0255000-7fd6a0259000 r--p 001bd000 103:05 795936 /lib/x86_64-linux-gnu/libc-2.24.so
7fd6a0259000-7fd6a025b000 rw-p 001c1000 103:05 795936 /lib/x86_64-linux-gnu/libc-2.24.so
7fd6a025b000-7fd6a025f000 rw-p 00000000 00:00 0
7fd6a025f000-7fd6a0275000 r-xp 00000000 103:05 791133 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fd6a0275000-7fd6a0474000 ---p 00016000 103:05 791133 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fd6a0474000-7fd6a0475000 r--p 00015000 103:05 791133 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fd6a0475000-7fd6a0476000 rw-p 00016000 103:05 791133 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fd6a0476000-7fd6a04a3000 r-xp 00000000 103:05 4335250 /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
7fd6a04a3000-7fd6a06a2000 ---p 0002d000 103:05 4335250 /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
7fd6a06a2000-7fd6a06a3000 r--p 0002c000 103:05 4335250 /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
7fd6a06a3000-7fd6a06a4000 rw-p 0002d000 103:05 4335250 /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
7fd6a06a4000-7fd6a07ac000 r-xp 00000000 103:05 795940 /lib/x86_64-linux-gnu/libm-2.24.so
7fd6a07ac000-7fd6a09ab000 ---p 00108000 103:05 795940 /lib/x86_64-linux-gnu/libm-2.24.so
7fd6a09ab000-7fd6a09ac000 r--p 00107000 103:05 795940 /lib/x86_64-linux-gnu/libm-2.24.so
7fd6a09ac000-7fd6a09ad000 rw-p 00108000 103:05 795940 /lib/x86_64-linux-gnu/libm-2.24.so
7fd6a09ad000-7fd6a0b26000 r-xp 00000000 103:05 4335931 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
7fd6a0b26000-7fd6a0d25000 ---p 00179000 103:05 4335931 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
7fd6a0d25000-7fd6a0d2f000 r--p 00178000 103:05 4335931 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
7fd6a0d2f000-7fd6a0d31000 rw-p 00182000 103:05 4335931 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
7fd6a0d31000-7fd6a0d35000 rw-p 00000000 00:00 0
7fd6a0d35000-7fd6a0d4d000 r-xp 00000000 103:05 795951 /lib/x86_64-linux-gnu/libpthread-2.24.so
7fd6a0d4d000-7fd6a0f4d000 ---p 00018000 103:05 795951 /lib/x86_64-linux-gnu/libpthread-2.24.so
7fd6a0f4d000-7fd6a0f4e000 r--p 00018000 103:05 795951 /lib/x86_64-linux-gnu/libpthread-2.24.so
7fd6a0f4e000-7fd6a0f4f000 rw-p 00019000 103:05 795951 /lib/x86_64-linux-gnu/libpthread-2.24.so
7fd6a0f4f000-7fd6a0f53000 rw-p 00000000 00:00 0
7fd6a0f53000-7fd6a0f79000 r-xp 00000000 103:05 795932 /lib/x86_64-linux-gnu/ld-2.24.so
7fd6a114b000-7fd6a1150000 rw-p 00000000 00:00 0
7fd6a1174000-7fd6a1178000 rw-p 00000000 00:00 0
7fd6a1178000-7fd6a1179000 r--p 00025000 103:05 795932 /lib/x86_64-linux-gnu/ld-2.24.so
7fd6a1179000-7fd6a117a000 rw-p 00026000 103:05 795932 /lib/x86_64-linux-gnu/ld-2.24.so
7fd6a117a000-7fd6a117b000 rw-p 00000000 00:00 0
7fff9e622000-7fff9e643000 rw-p 00000000 00:00 0 [stack]
7fff9e714000-7fff9e716000 r--p 00000000 00:00 0 [vvar]
7fff9e716000-7fff9e718000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
TL;DR: Your KeyType is a std::string and consequently non-pod. The STXXL does not support this.
See section Parameterizing STXXL Containers in the official STXXL FAQ.
See How to use std::string as key in stxxl::map here, where somebody had the same issue. Answers below that question describe possible workarounds.

Redirection of crash output

I've found that some programs print Memory Maps and other diagnostic information to the terminal when they crash, even when I redirect file descriptors 1 and 2 (standard out and error, respectively) to files. How can I redirect the diagnostics to a file?
For example, this c++ program:
#include <iostream>
#include <assert.h>
#include <string>
int main(){
using namespace std;
cout<<"foo"<<endl;
cerr<<"bar"<<endl;
string s;
s = "asdf";
delete &s;
}
After compilation, it can be run, redirecting "all" output (g++ foo.cpp && ./a.out > /dev/null 2>&1) but still print the following to the terminal:
======*** Error in `./a.out': double free or corruption (out): 0x00007ffe389313d0 ***
======= Backtrace: =========
/usr/lib/libc.so.6(+0x722ab)[0x7fc7c053f2ab]
/usr/lib/libc.so.6(+0x7890e)[0x7fc7c054590e]
/usr/lib/libc.so.6(+0x7911e)[0x7fc7c054611e]
./a.out[0x400b41]
/usr/lib/libc.so.6(__libc_start_main+0xf1)[0x7fc7c04ed511]
./a.out[0x4009fa]
= Memory map: ========
00400000-00401000 r-xp 00000000 00:27 531373 /tmp/a.out
00601000-00602000 r--p 00001000 00:27 531373 /tmp/a.out
00602000-00603000 rw-p 00002000 00:27 531373 /tmp/a.out
01f1d000-01f4f000 rw-p 00000000 00:00 0 [heap]
7fc7bc000000-7fc7bc021000 rw-p 00000000 00:00 0
7fc7bc021000-7fc7c0000000 ---p 00000000 00:00 0
7fc7c04cd000-7fc7c0668000 r-xp 00000000 08:09 142916 /usr/lib/libc-2.25.so
7fc7c0668000-7fc7c0867000 ---p 0019b000 08:09 142916 /usr/lib/libc-2.25.so
7fc7c0867000-7fc7c086b000 r--p 0019a000 08:09 142916 /usr/lib/libc-2.25.so
7fc7c086b000-7fc7c086d000 rw-p 0019e000 08:09 142916 /usr/lib/libc-2.25.so
7fc7c086d000-7fc7c0871000 rw-p 00000000 00:00 0
7fc7c0871000-7fc7c0887000 r-xp 00000000 08:09 144514 /usr/lib/libgcc_s.so.1
7fc7c0887000-7fc7c0a86000 ---p 00016000 08:09 144514 /usr/lib/libgcc_s.so.1
7fc7c0a86000-7fc7c0a87000 r--p 00015000 08:09 144514 /usr/lib/libgcc_s.so.1
7fc7c0a87000-7fc7c0a88000 rw-p 00016000 08:09 144514 /usr/lib/libgcc_s.so.1
7fc7c0a88000-7fc7c0b9a000 r-xp 00000000 08:09 131998 /usr/lib/libm-2.25.so
7fc7c0b9a000-7fc7c0d99000 ---p 00112000 08:09 131998 /usr/lib/libm-2.25.so
7fc7c0d99000-7fc7c0d9a000 r--p 00111000 08:09 131998 /usr/lib/libm-2.25.so
7fc7c0d9a000-7fc7c0d9b000 rw-p 00112000 08:09 131998 /usr/lib/libm-2.25.so
7fc7c0d9b000-7fc7c0f13000 r-xp 00000000 08:09 141919 /usr/lib/libstdc++.so.6.0.22
7fc7c0f13000-7fc7c1113000 ---p 00178000 08:09 141919 /usr/lib/libstdc++.so.6.0.22
7fc7c1113000-7fc7c111d000 r--p 00178000 08:09 141919 /usr/lib/libstdc++.so.6.0.22
7fc7c111d000-7fc7c111f000 rw-p 00182000 08:09 141919 /usr/lib/libstdc++.so.6.0.22
7fc7c111f000-7fc7c1123000 rw-p 00000000 00:00 0
7fc7c1123000-7fc7c1146000 r-xp 00000000 08:09 142957 /usr/lib/ld-2.25.so
7fc7c1318000-7fc7c131e000 rw-p 00000000 00:00 0
7fc7c1344000-7fc7c1345000 rw-p 00000000 00:00 0
7fc7c1345000-7fc7c1346000 r--p 00022000 08:09 142957 /usr/lib/ld-2.25.so
7fc7c1346000-7fc7c1347000 rw-p 00023000 08:09 142957 /usr/lib/ld-2.25.so
7fc7c1347000-7fc7c1348000 rw-p 00000000 00:00 0
7ffe38911000-7ffe38932000 rw-p 00000000 00:00 0 [stack]
7ffe38945000-7ffe38947000 r--p 00000000 00:00 0 [vvar]
7ffe38947000-7ffe38949000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted (core dumped)
To redirrect output from /dev/tty to a file you can do:
script -q -c 'g++ foo.cpp && ./a.out' /dev/null > /tmp/bla.txt
Taken from here - How to redirect a program that writes to tty?

How to interpret memory map dump output?

my question is not relative to the error itself (I know what is the reason for it).
I would instead like to know how to read this dump (meaning of the fields, flags and so on), where it is produced (glibc, or gcc libraries) and how I can infer what's wrong from it at a higher level (e.g. some tool that might find this output useful).
*** glibc detected *** python: double free or corruption (fasttop): 0x0000000006c4eb90 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7f6c3a0a1b96]
/usr/lib/nvidia-current-updates/tls/libnvidia-tls.so.304.88(+0x1cc1)[0x7f6c2e544cc1]
======= Memory map: ========
00400000-00401000 r-xp 00000000 08:07 2238049 /build/bin/python
00600000-00601000 r--p 00000000 08:07 2238049 /build/bin/python
00601000-00602000 rw-p 00001000 08:07 2238049 /build/bin/python
00954000-07625000 rw-p 00000000 00:00 0 [heap]
40c14000-40c92000 rw-p 00000000 00:00 0
7f6c04000000-7f6c041bc000 rw-p 00000000 00:00 0
7f6c041bc000-7f6c08000000 ---p 00000000 00:00 0
7f6c08000000-7f6c081bc000 rw-p 00000000 00:00 0
7f6c081bc000-7f6c0c000000 ---p 00000000 00:00 0
7f6c0c000000-7f6c0c1bc000 rw-p 00000000 00:00 0
7f6c0c1bc000-7f6c10000000 ---p 00000000 00:00 0
7f6c14000000-7f6c14021000 rw-p 00000000 00:00 0
7f6c14021000-7f6c18000000 ---p 00000000 00:00 0
7f6c1ab5a000-7f6c1ab5b000 ---p 00000000 00:00 0
7f6c1ab5b000-7f6c1af5b000 rwxp 00000000 00:00 0
7f6c1af5b000-7f6c1af5c000 ---p 00000000 00:00 0
7f6c1af5c000-7f6c1b35c000 rwxp 00000000 00:00 0
7f6c1b35c000-7f6c1b35d000 ---p 00000000 00:00 0
7f6c1b35d000-7f6c1b75d000 rwxp 00000000 00:00 0
7f6c1b75d000-7f6c1b767000 r-xp 00000000 08:05 1314563 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f6c1b767000-7f6c1b967000 ---p 0000a000 08:05 1314563 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f6c1b967000-7f6c1b968000 r--p 0000a000 08:05 1314563 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f6c1b968000-7f6c1b969000 rw-p 0000b000 08:05 1314563 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f6c1b969000-7f6c1b980000 r-xp 00000000 08:05 1314576 /lib/x86_64-linux-gnu/libnsl-2.15.so
The man page for proc has the answer. The memory map output format is given in the entry for /proc/[pid]/maps.
The short summary is going across the columns it is: memory range, permissions, offset, device (major:minor), inode, and pathname.

*** buffer overflow detected ***

my program was compiled properly with "make" on Ubuntu 11.04, but when i run it, it give error.
is this a bug on Ubuntu? or this is difference in variable types between compilers?
pls help me
*** buffer overflow detected ***: src/trilearn_player terminated
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x50)[0x9cd0a0]
/lib/i386-linux-gnu/libc.so.6(+0xe5f7a)[0x9cbf7a]
/lib/i386-linux-gnu/libc.so.6(__strcpy_chk+0x3f)[0x9cb30f]
src/trilearn_player[0x804dd24]
src/trilearn_player[0x808b2d5]
src/trilearn_player[0x80920cf]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x8fce37]
src/trilearn_player[0x804a421]
======= Memory map: ========
00139000-0015d000 r-xp 00000000 08:0b 6060 /lib/i386-linux-gnu/libm-2.13.so
0015d000-0015e000 r--p 00023000 08:0b 6060 /lib/i386-linux-gnu/libm-2.13.so
0015e000-0015f000 rw-p 00024000 08:0b 6060 /lib/i386-linux-gnu/libm-2.13.so
001b4000-001b5000 r-xp 00000000 00:00 0 [vdso]
00488000-0049d000 r-xp 00000000 08:0b 6831 /lib/i386-linux-gnu/libpthread-2.13.so
0049d000-0049e000 r--p 00015000 08:0b 6831 /lib/i386-linux-gnu/libpthread-2.13.so
0049e000-0049f000 rw-p 00016000 08:0b 6831 /lib/i386-linux-gnu/libpthread-2.13.so
0049f000-004a1000 rw-p 00000000 00:00 0
00558000-00637000 r-xp 00000000 08:0b 134145
00637000-0063b000 r--p 000de000 08:0b 134145 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.14
0063b000-0063c000 rw-p 000e2000 08:0b 134145 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.14
0063c000-00643000 rw-p 00000000 00:00 0
0087b000-00885000 r-xp 00000000 08:0b 6826 /lib/i386-linux-gnu/libnss_files-2.13.so
00885000-00886000 r--p 00009000 08:0b 6826 /lib/i386-linux-gnu/libnss_files-2.13.so
00886000-00887000 rw-p 0000a000 08:0b 6826 /lib/i386-linux-gnu/libnss_files-2.13.so
008e6000-00a42000 r-xp 00000000 08:0b 5792 /lib/i386-linux-gnu/libc-2.13.so
/lib/i386-linux-gnu/libc.so.6(__strcpy_chk+0x3f)[0x9cb30f]
Looks like you copy too many chars to the destination.

Resources