Segfault mit gdb Fehlerausgabe
-
nicht nur der typ von w.url wäre interessant.
vor allem der typ von url wäre echt gut zu wissen ;o)
wozu ist count eigtl da?bb
-
Dein Copy-Konstruktor versucht an der Stelle nicht zufällig ein Objekt sich selbst zuzuweisen?
-
url ist ein std::string und keine std::string&
count ist ein uint32_tWas meinst Du mit ein Objekt sich selbst zuweisen?
-
HändyÄndy schrieb:
url ist ein std::string und keine std::string&
count ist ein uint32_tWas meinst Du mit ein Objekt sich selbst zuweisen?
Bei Kopierkonstruktoren sollte man aufpassen (wenn die Klasse dynamischen Speicher benutzt), dass ein Objekt nicht sich selbst zugewiesen wird, sonst kann man ein paar sehr subtile und schwer zu findende Fehler erzeugen:
http://www.parashift.com/c++-faq-lite/assignment-operators.html
Wenn url jedoch ein std::string ist, sollte dies aber eigentlich nichts ausmachen.Kannst du das Programm zu einem compilierbaren Minimalbeispiel kürzen?
-
Das sieht mir eher nach einen Folgefehler aus. Irgendwo vorher gab es mal undefiniertes Verhalten und hier kommt es halt zum tragen.
-
Ich habe mal Valgrind laufen lassen. Kann mit den Infos aber irgendwie nix anfangen
valgrind: m_mallocfree.c:194 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.
valgrind: Heap block lo/hi size mismatch: lo = 80, hi = 4294967376.
Probably caused by overrunning/underrunning a heap block's bounds.==28107== at 0x380176D7: report_and_quit (m_libcassert.c:136)
==28107== by 0x38017A3A: vgPlain_assert_fail (m_libcassert.c:200)
==28107== by 0x3802031D: vgPlain_arena_free (m_mallocfree.c:191)
==28107== by 0x380354FF: vgPlain_cli_free (replacemalloc_core.c:108)
==28107== by 0x380017F9: die_and_free_mem (mc_malloc_wrappers.c:111)
==28107== by 0x38035BA7: do_client_request (scheduler.c:1158)
==28107== by 0x380372B1: vgPlain_scheduler (scheduler.c:869)
==28107== by 0x38051B59: run_a_thread_NORETURN (syswrap-linux.c:87)sched status:
running_tid=1Thread 1: status = VgTs_Runnable
==28107== at 0x4A05130: operator delete(void*) (vg_replace_malloc.c:244)
==28107== by 0x41C89E: __gnu_cxx::new_allocator<boost::unordered_detail::hash_node<std::allocator<std::pair<std::string const, ddos_webpage> >, boost::unordered_detail::ungrouped> >::deallocate(boost::unordered_detail::hash_node<std::allocator<std::pair<std::string const, ddos_webpage> >, boost::unordered_detail::ungrouped>, unsigned long) (new_allocator.h:94)
==28107== by 0x41D914: boost::unordered_detail::hash_buckets<std::allocator<std::pair<std::string const, ddos_webpage> >, boost::unordered_detail::ungrouped>::delete_node(boost::unordered_detail::hash_bucket<std::allocator<std::pair<std::string const, ddos_webpage> > >) (buckets.hpp:70)
==28107== by 0x41D95F: boost::unordered_detail::hash_buckets<std::allocator<std::pair<std::string const, ddos_webpage> >, boost::unordered_detail::ungrouped>::clear_bucket(boost::unordered_detail::hash_bucket<std::allocator<std::pair<std::string const, ddos_webpage> > >) (buckets.hpp:82)
==28107== by 0x41D9A7: boost::unordered_detail::hash_buckets<std::allocator<std::pair<std::string const, ddos_webpage> >, boost::unordered_detail::ungrouped>::delete_buckets() (buckets.hpp:92)
==28107== by 0x41DA4D: boost::unordered_detail::hash_buckets<std::allocator<std::pair<std::string const, ddos_webpage> >, boost::unordered_detail::ungrouped>::~hash_buckets() (buckets.hpp:135)
==28107== by 0x41DABB: boost::unordered_detail::hash_table<boost::unordered_detail::map<std::string, boost::hashstd::string, std::equal_tostd::string, std::allocator<std::pair<std::string const, ddos_webpage> > > >::~hash_table() (fwd.hpp:492)
==28107== by 0x41DAD2: boost::unordered_detail::hash_unique_table<boost::unordered_detail::map<std::string, boost::hashstd::string, std::equal_tostd::string, std::allocator<std::pair<std::string const, ddos_webpage> > > >::~hash_unique_table() (fwd.hpp:604)
==28107== by 0x41DAEA: boost::unordered_map<std::string, ddos_webpage, boost::hashstd::string, std::equal_tostd::string, std::allocator<std::pair<std::string const, ddos_webpage> > >::~unordered_map() (unordered_map.hpp:160)
==28107== by 0x414200: Processor::processPacket(_hend_packet, int) (ddos_main.cpp:190)
==28107== by 0x4142A5: ddos_packet_in (ddos_main.cpp:272)
==28107== by 0x410CE1: autolart (autolart.c:37)
==28107== by 0x40DCC4: packet (hendread.c:913)
==28107== by 0x410BC6: main (hendread.c:1688)Hat jemand eine Idee was mir diese Ausgabe sagt? Ich gehe mal nicht davon aus, dass ich nenn Fehler in der boost Bibliothek gefunden habe ;).
-
Ich hab den Fehler gefunden.
In einer Methode habe ich den Index für ein Array ermittelt. Blöderweise habe ich dazu einen falschen Index zurückgeliefert. Jetzt läufts.
Völlig trivialer Flüchtigkeitsfehler. Unfassbar!!!

-
HändyÄndy schrieb:
//Copy Konstruktor ddos_webpage::ddos_webpage( const ddos_webpage& w ) {Was soll denn das werden?
-
Das ist doch ein Copy-Konstruktor?
-
Nein, ich meine, was soll denn das Programm schlussendlich werden? ddos_webpage ist ein ziemlich verdächtiger Bezeichner.
-
Ja, ein verdächtiger Name
, aber tatsächlich soll es DDoS Attacken erkennen. Also genau das Gegenteil. Das Programm wird, wenn es fertig ist eine Kopie des Traffics eines der größten europäischen Webhoster erhalten und anschließend in Echtzeit auf einem dedizierten Rechner beurteilen, ob ein DDoS Angriff auf eine Webseite stattfindet oder nicht. Darauf hin werden dann die Admins benachrichtigt.