C++ Probleme...

bsd4me · 4 Juli 2018

Hallo,

ich möchte die Software REPET (https://urgi.versailles.inra.fr/Tools/REPET) auf einem FreeBSD Server laufen lassen. Es scheint alles zu klappen, bis auf das Executable grouper. Dafür habe ich sogar den Quellcode bekommen, da die Binaries nur für Linux geschrieben wurden und neu compiliert. Hier ist die Fehlersituation:

[user@server] > lldb40 $REPET_PATH/bin/grouper -c grouperThreads2.26.core
(lldb) target create "/bioappl/src/REPET/REPET_linux-x64-2.5/bin/grouper" --core "grouperThreads2.26.core"
Core file '/home/user/work/DmelChr4_TEannot/DmelChr4_Blaster_Grouper/grouperThreads2.26.core' (x86_64) was loaded.
(lldb) bt
* thread #1, name = 'grouperThreads2.26', stop reason = signal SIGSEGV
* frame #0: 0x00000000004bde75 grouper`Range::Range(Range const&) + 37
frame #1: 0x00000000004be1ba grouper`RangeAlign::RangeAlign(RangeAlign const&) + 42
frame #2: 0x0000000000457240 grouper`RangePair::RangePair(RangePair const&) + 48
frame #3: 0x0000000000456dd0 grouper`std::__1::list<RangePair, std::__1::allocator<RangePair> >:

ush_back(RangePair const&) + 768
frame #4: 0x0000000000456a5d grouper`std::__1::list<RangePair, std::__1::allocator<RangePair> >::list(std::__1::list<RangePair, std::__1::allocator<RangePair> > const&) + 781
frame #5: 0x0000000000456723 grouper`RangePairSet::RangePairSet(RangePairSet const&) + 67
frame #6: 0x0000000000456060 grouper`std::__1::list<RangePairSet, std::__1::allocator<RangePairSet> >:

ush_back(RangePairSet const&) + 768
frame #7: 0x0000000000455ced grouper`std::__1::list<RangePairSet, std::__1::allocator<RangePairSet> >::list(std::__1::list<RangePairSet, std::__1::allocator<RangePairSet> > const&) + 781
frame #8: 0x0000000000452560 grouper`std::__1::list<std::__1::list<RangePairSet, std::__1::allocator<RangePairSet> >, std::__1::allocator<std::__1::list<RangePairSet, std::__1::allocator<RangePairSet> > > >:

ush_back(std::__1::list<RangePairSet, std::__1::allocator<RangePairSet> > const&) + 768
frame #9: 0x000000000044fa51 grouper`splitInputData(std::__1::list<RangePairSet, std::__1::allocator<RangePairSet> >&, int) + 2561
frame #10: 0x0000000000450464 grouper`main + 1652
frame #11: 0x0000000000404a6f grouper`_start + 367

was dem Quellecode

std::list< std::list<RangePairSet> > splitInputData(std::list<RangePairSet>& rp_list, int nb_split)
{
std::list< std::list<RangePairSet> > lrpl;
rp_list.sort( RangePair::greaterLengthIdent );

int size=rp_list.size();
int chunk=floor(size/nb_split);
std::cout<<"chunks="<<chunk<<" from "<<size<<" matches"<<std::endl;
std::list<RangePairSet>::iterator rp_list_it=rp_list.begin();
for(int i=0; i<nb_split; i++)
{
std::list<RangePairSet> rpl;
for(int j=0; j<chunk && rp_list_it!=rp_list.end(); j++) rp_list_it++; // move iterator from several position
if(rp_list_it!=rp_list.end())
rpl.splice(rpl.begin(), rp_list, rp_list.begin(), rp_list_it);
else
rpl.splice(rpl.begin(), rp_list, rp_list.begin());
lrpl.push_back(rpl);
}
lrpl.back().splice(lrpl.back().begin(),rp_list);
return lrpl;
}

entspricht. die dick markierte Zeile produziert den Fehler... Hat evtl. jeamnd eine Idee warum?

Vielen Dank und viele Grüße, Norbert

schorsch_76 · 4 Juli 2018

Wie du auch siehst ist

Code:

frame #0: 0x00000000004bde75 grouper`Range::Range(Range const&) + 37

der CopyConstructor von Range. Hier Kracht es. Der Push ruft den CopyConstructor nur auf. Was passier in dem CopyConstructor? Hast du hier den Code?

bsd4me · 4 Juli 2018

na super

die Range Klasse sieht so aus: es gibt nur einen Rang.h Datei - zum Hochladen musste ich sie umbenennen

schorsch_76 · 4 Juli 2018

Die Klasse hat nur 2 unsigned long Member. Wenn das crasht, ist meist das Ziel im "Nirvana" (aka invalid pointer). Die Liste ist auf dem Stack, dann ist das normalerweise kein Problem. Es könnte aber auch noch ein korrupter Stack sein.

Hier würde ich das Projekt mit (-fsanitize=address) (im Debug Build) Siehe [1]

[1] https://clang.llvm.org/docs/AddressSanitizer.html

Ein Beispiel

Code:

void bar(int j) {
    int *addr = (&j) - 20;
    for(int i = 0; i <= 1000; i++) {
        *(addr + i) = 0xDEADBEEF;
    }
}

int main() {
    bar(10);
    return 0;
}

Code:

clang++ -g -O0 -fsanitize=address main.cpp
/usr/local/bin/gdb ./a.out
GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD]
Copyright (C) 2018 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-portbld-freebsd11.1".
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 ./a.out...done.
(gdb) start
Temporary breakpoint 1 at 0x4936b4: file main.cpp, line 9.
Starting program: /tmp/a.out

Temporary breakpoint 1, main () at main.cpp:9
9           bar(10);
(gdb) c
Continuing.
=================================================================
==1674==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7fffffffe340 at pc 0x00000049362d bp 0x7fffffffe330 sp 0x7fffffffe328
WRITE of size 4 at 0x7fffffffe340 thread T16777215
    #0 0x49362c  (/tmp/a.out+0x49362c)
    #1 0x4936b8  (/tmp/a.out+0x4936b8)
    #2 0x40de64  (/tmp/a.out+0x40de64)
    #3 0x8006d5fff  (<unknown module>)

Address 0x7fffffffe340 is located in stack of thread T0 at offset 0 in frame
    #0 0x4934af  (/tmp/a.out+0x4934af)

  This frame has 1 object(s):
    [32, 36) 'j.addr'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow (/tmp/a.out+0x49362c)
Shadow bytes around the buggy address:
  0x4ffffffffc10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x4ffffffffc20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x4ffffffffc30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x4ffffffffc40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x4ffffffffc50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x4ffffffffc60: 00 00 00 00 00 00 00 00[f1]f1 f1 f1 04 f3 f3 f3
  0x4ffffffffc70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x4ffffffffc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x4ffffffffc90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x4ffffffffca0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x4ffffffffcb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==1674==ABORTING
[Inferior 1 (process 1674) exited with code 01]
(gdb) bt
No stack.
(gdb) info line *0x49362c
Line 4 of "main.cpp" starts at address 0x4935da <bar(int)+314> and ends at 0x493637 <bar(int)+407>.
(gdb)

KobRheTilla · 5 Juli 2018

Vielleicht hilft auch ein Lauf im Valgrind.

Rob

kith · 5 Juli 2018

Bitte mit einem Aussagekräftigem Threadtitel den Moderator kontaktieren.

C++ Probleme...

bsd4me

Well-Known Member

schorsch_76

FreeBSD Fanboy

bsd4me

Well-Known Member

Anhänge

schorsch_76

FreeBSD Fanboy

KobRheTilla

used register

kith

unfuck me!

Wir schützen deine Privatsphäre