abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 17:35 | Bezpečnostní upozornění

Německá Bundesnetzagentur (obdoba českého ČTU) zakázala na německém území prodej panenky Cayla kvůli „špionáži“ dětí. Tato elektronická hračka obsahuje mikrofon, reproduktor a kameru a bezdrátové komunikační rozhraní, pomocí kterého se hračka připojuje na servery výrobce. Takovýmto způsobem může hračka pomocí umělé inteligence „odpovídat“ na dotazy dítěte. Hlavní problém bude ale asi někde jinde, podle prvotních zpráv může

… více »
Petr Tomášek | Komentářů: 21
17.2. 15:30 | Bezpečnostní upozornění

CSIRT.CZ upozorňuje, že bezpečnostní experti objevili nový typ malwaru, jenž cílí na open source e-commerce platformu Magento. Malware je zajímavý tím, že se jedná o první svého druhu, jehož kód zůstává skrytý v SQL databázi zasaženého e-shopu. Škodlivý kód je volán pomocí tzv. SQL trigerru, který je spouštěn při každém vytvoření objednávky v systému.

Ladislav Hagara | Komentářů: 0
17.2. 09:00 | Nová verze

Bylo vydáno Ubuntu 16.04.2 LTS, tj. druhé opravné vydání Ubuntu 16.04 LTS s kódovým názvem Xenial Xerus. Přehled novinek v poznámkách k vydání a v přehledu změn.

Ladislav Hagara | Komentářů: 37
17.2. 06:00 | Zajímavý článek

Pavel Tišnovský se v dvoudílném článku na MojeFedora.cz věnuje tvorbě pluginů (modulů) pro bitmapový grafický editor GIMP. Pomocí pluginů lze GIMP rozšiřovat o další funkce. Implementovat lze například nové filtry nebo pomocné utility pro tvorbu animací či poloautomatickou retuš snímků.

Ladislav Hagara | Komentářů: 6
16.2. 23:32 | Komunita

Do 30. března se lze přihlásit do dalšího kola programu Outreachy, jehož cílem je přitáhnout do světa svobodného a otevřeného softwaru lidi ze skupin, jež jsou ve světě svobodného a otevřeného softwaru málo zastoupeny. Za 3 měsíce práce, od 30. května do 30. srpna 2017, v participujících organizacích lze vydělat 5 500 USD. Jedná se již o 14. kolo tohoto programu.

Ladislav Hagara | Komentářů: 11
16.2. 23:13 | Nová verze

Byla vydána verze 0.92.1 svobodného multiplatformního vektorového grafického editoru Inkscape. Přehled novinek v poznámkách k vydání. Řešen je mimo jiné problém s verzí 0.92, jež rozbíjí dokumenty vytvořené v předchozích verzích Inkscape. Více v příspěvku na blogu Davida Revoye, autora open source webového komiksu Pepper&Carrot nebo portrétu GNU/Linuxu.

Ladislav Hagara | Komentářů: 0
16.2. 16:26 | Bezpečnostní upozornění

Byla vydána verze 1.1.0e kryptografické knihovny OpenSSL. Dle bezpečnostního upozornění 20170216 byla opravena závažná bezpečnostní chyba CVE-2017-3733.

Ladislav Hagara | Komentářů: 1
16.2. 13:03 | Pozvánky

GNOME hackaton proběhne v Brně na FIT VUT v Red Hat Labu (budova Q) v pondělí 20. února od 15:00. Registrace není nutná, ale pokud dáte na FaceBooku vědět, že plánujete dorazit, pomůže to s plánováním.

Ladislav Hagara | Komentářů: 0
16.2. 13:02 | Pozvánky

Únorový Prague Containers Meetup se koná 21. února v budově MSD. Můžete se těšit na přednášky o tom, proč a jak používat kontejnery a zároveň získat zajímavý pohled na historii a budoucnost kontejnerů.

little-drunk-jesus | Komentářů: 0
16.2. 08:55 | Zajímavý software

Google na svém blogu věnovaném vývojářům oznámil vydání verze 1.0 open source knihovny pro strojové učení TensorFlow (Wikipedie). Přehled novinek v poznámkách k vydání na GitHubu. Zdrojové kódy TensorFlow jsou k dispozici pod licencí Apache 2.0.

Ladislav Hagara | Komentářů: 0
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (13%)
 (2%)
 (72%)
 (3%)
 (10%)
Celkem 656 hlasů
 Komentářů: 52, poslední 13.2. 12:45
Rozcestník
Reklama

Dotaz: program padá na SIGSEGV, jak odladit?

8.12.2010 04:01 Franta Hanzlík
program padá na SIGSEGV, jak odladit?
Přečteno: 1312×
Sestavil jsem program (ne svůj), ten ale po spuštěni (zřejmě ještě ve fázi nějaké inicializace) padá na SEGV. Po doinstalaci příslušných debuginfo balíčků vypadá backtrace takto:
#0  _dl_lookup_symbol_x (undef_name=0x30bde3 "using_xterm", undef_map=0x862e0a0, ref=0xbffef550, symbol_scope=0x862e258, version=0x0, type_class=1, 
    flags=1, skip_map=0x0) at dl-lookup.c:713
#1  0x00110c98 in _dl_fixup (l=<value optimized out>, reloc_arg=<value optimized out>) at dl-runtime.c:118
#2  0x001174f0 in _dl_runtime_resolve () at ../sysdeps/i386/dl-trampoline.S:37
#3  0x0030e1eb in terminal_initialize () at terminal.c:404
#4  0x080e5297 in iodev_init () at dev_list.c:107
#5  0x0805e335 in main (argc=1, argv=0xbffff764) at emu.c:426
Nevíte někdo co s tím? Těm bodům #3 - #0 nerozumím, předpokládám, že jsou to nějaké rutiny glibc, ale netuším o co tam přesně jde a po čem bych měl jít. Příp. zná někdo odkazy na nějakou slušnou nalejvárnu z téhle oblasti?
Díky předem.

Odpovědi

8.12.2010 09:15 rastos | skóre: 60 | blog: rastos
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
Máš k tomu zdrojáky, nie? Tak čo je na riadku 404 v súbore terminal.c ?
8.12.2010 10:10 Franta Hanzlík
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
No, nic co by vypadalo závadně:
    403 
    404    if (using_xterm())
    405      Video_term.change_config = term_change_config;
Ta funkce "using_xterm()" je definována ve stejném zdrojáku o kousek výše takhle:
    305 
    306 int using_xterm(void)
    307 {
    308    char *term = getenv("TERM");
    309 
    310    if (term == NULL)
    311       return 0;
    312    
    313    return !strncmp("xterm", term, 5) ||
    314            !strncmp("rxvt", term, 4) ||
    315            !strcmp("dtterm", term);
    316 }
    317 
Na tom nic špatného taky nevidím, a ten backtrace do toho IMO neukazuje. V položené otázce mám chybu, nerozumím bodům #2 - #0, ten #3 je ještě jasný. Ale zbytek?

Ještě pro upřesnění - na Fedoře 12-13/i386 mi stejný program ze stejných zdrojáků sestavený se stejnými volbami chodí dobře, na několika počítačích.

8.12.2010 11:02 Franta Hanzlík
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
Ještě poznatek, jestli to může být užitečné:
1) Našel jsem počítač s Fedorou 14, kde program také běhá.
2) na počítačích, kde krachuje, je jedno, zda jej spustím v consoli (TERM=linux) nebo v gnome-terminal (TERM=xterm), krachuje to stejně. Radši bych, než nějaké porovnávání konfigurace PC kde to chodí a kde ne, viděl nějaký obecný postup, jak se takovéhle problémy řeší, a co znamenají ta poslední tři volání na stacku. Máte někdo nějaký nápad?
8.12.2010 13:05 rastos | skóre: 60 | blog: rastos
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
Niečo je zle. To using_xterm nie je v backtrace. To znamená, že buď je to tam nejak #ifdef-nuté a to using_xterm sa skutočnosti hľadá inde a nenájde sa, alebo je došahaný stack.

a) Čo povie

nm terminal.o |grep using_xterm

?

b) môžeš to pustiť pod valgrind-om?
8.12.2010 14:11 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
Podle toho backtrace bych tipoval, že se funkce using_xterm() linkuje z dynamické knihovny a právě při tom nastává problém, ne až při jejím spuštění.
8.12.2010 14:42 Franta Hanzlík
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
Jojo, některé věci si natahuje dynamicky. Příslušný kousek Makefile je zhruba:
USE_DL_PLUGINS=1        # Hlavni Makefile.conf

CFILES=term_core.c terminal.c keyb_slang.c mouse_xterm.c
OBJS=$(CFILES:.c=.o)
ifdef USE_DL_PLUGINS
$(BINPATH)/bin/libplugin_term.so: $(OBJS) $(MAPS)
        $(CC) $(LDFLAGS) -shared -o $@ $(OBJS) $(SLANGLIB)
        $(AR) crs $(LIB)
endif
a binární části jsou zhruba:
/usr/bin/xdosemu.bin
/usr/lib/dosemu
/usr/lib/dosemu/libplugin_X.so
/usr/lib/dosemu/libplugin_alsa.so
/usr/lib/dosemu/libplugin_gpm.so
/usr/lib/dosemu/libplugin_sdl.so
/usr/lib/dosemu/libplugin_sndfile.so
/usr/lib/dosemu/libplugin_term.so
Ale co s tím? Jak postupovat dál?
13.12.2010 16:04 Franta Hanzlík
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
Tak dynamické knihovny s tím asi nesouvisí. Program se dá přeložit i bez nich, což jsem udělal - a výsledek je stejný, program padá i tak, úplně stejně.

Teď jsem do programu přidal pár ladicích výpisů do oblasti, kde docházalo k pádu - a program padá také, ale v trochu jiném místě.

Podle zdrojáků program chvíli předtím než padne několikrát volá mprotect() na různé oblasti svého kódu, nastavuje je readonly atd, takže je klidně možné, že k SEGV dojde nejen při sahnutí mimo oblast programu, ale i uvnitř.

Současný pád a backtrace vypadá takto:
Program received signal SIGSEGV, Segmentation fault.
_dl_lookup_symbol_x (undef_name=0x804abb3 "setreuid", undef_map=0x123900, ref=0xbffef4d0, symbol_scope=0x123ab8, version=0xb7fe5438, type_class=1, flags=1, 
    skip_map=0x0) at dl-lookup.c:713
713	{
(gdb) bt
#0  _dl_lookup_symbol_x (undef_name=0x804abb3 "setreuid", undef_map=0x123900, ref=0xbffef4d0, symbol_scope=0x123ab8, version=0xb7fe5438, type_class=1, 
    flags=1, skip_map=0x0) at dl-lookup.c:713
#1  0x00110c98 in _dl_fixup (l=<value optimized out>, reloc_arg=<value optimized out>) at dl-runtime.c:118
#2  0x001174f0 in _dl_runtime_resolve () at ../sysdeps/i386/dl-trampoline.S:37
#3  0x080886f7 in priv_drop () at priv.c:187
#4  0x0804e616 in main (argc=4, argv=0xbffff5f4) at emu.c:404
Není mi jasné, co se tam může dít. "priv.c" na řádku 187 volá "setreuid" s parametry (500,500), to by mělo být OK a moc by se na tom dát zkazit nemělo.

Jak by se mělo postupovat dál?
Voty avatar 14.12.2010 07:14 Voty | skóre: 12 | blog: gemini
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
Pořád to souvisí s dynamickými knihovnami (viz _dl_xxx volání). V tomto případě se program pravděpodobně snaží najít tu funkci "setreuid". Ještě můžeš vyzkoušet

LD_BIND_NOW=y ./nazev_binarky

To by mělo způsobit, že se všechny symboly pokusí dynamic linker vyřešit všechny závislosti ještě před začátkem programu. Né, že by to potom začalo fungovat, ale bude jasné, že za to "může" dynamic linker.
Jednu rozbil a tu druhou ztratil.
14.12.2010 10:46 Franta Hanzlík
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
Tak to je trefa, tohle pomohlo na všech mašinách kde to nefachalo. Jinak, já vím že dyn. knihovny v programu jsou, viz můj výpis ldd programu někde tady, ale nějak naivně jsem si myslel, že ld.so je "neprůstřelný", že takovouhle chybu prostě udělat nemůže. Ale ve Fedoře občas krev teče, ve čtrnáctce je glibc s podezřelým číslem verze 2.12.90, tj do full-2.13 asi ještě něco chybí a její dynamic linker možná není úplně košer. Zajímal by mě názor někoho, kdo do toho trochu líp vidí.

Tenhle program má shell wrapper, takže nebude problém tam definici "LD_BIND_NOW" přidat (někde jsem našel, že ani nemusí mít hodnotu "y", stačí aby byla definovaná.

Asi by to taky mělo vyřešit linkování s volbou ld "-Wl,-z now", možná to zkusím radši tak.

Díky moc!
Voty avatar 14.12.2010 12:21 Voty | skóre: 12 | blog: gemini
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
Jasně, "LD_BIND_NOW" by mělo stačit, aby měla libovolnou hodnotu, to je pravda jak teď koukám :)

V jednotlivých verzích glibc se moc neorientu, takže tady nepomůžu. Avšak napadá mne, zda by nebylo možné, že program si omylem přepisuje někde v paměti co nemá a tím, že DL udělá vše již na začátku, tak to pak "jakoby nevadí", s tím, že něco může vykouknout trochu později. Tedy, že by stálo za to zjistit, co je původní příčinou.
Jednu rozbil a tu druhou ztratil.
14.12.2010 12:34 Franta Hanzlík
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
To asi možné je, tak jestli tedy mohu otravovat ještě jednou - jde v gdb nebo jiném ladicím toolu nastavit "breakpoint" typu "trace trap, if program sáhne na definované místo/oblast v paměti"?

Nebo je nějaká jiná metoda, jak zjistit, že si program něco v sobě přepisuje? Odhaduji, že u txt sekce by to jít mohlo(mělo), ale u ostatních?
Voty avatar 14.12.2010 19:04 Voty | skóre: 12 | blog: gemini
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
Mno :) Já bych to zkusil spustit znovu pod valgrind-em, ale hledal bych jen chyby, memory leaky nás (snad) nezajímají, takže kdyby to dokázalo najít nějaké chybné přístupy do paměti ...

Ačkoliv je stále možné, že chyba je skutečně v dotyčném DL (prohledal bych google na reporty).
Jednu rozbil a tu druhou ztratil.
14.12.2010 21:50 rastos | skóre: 60 | blog: rastos
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
(gdb) help awatch
Set a watchpoint for an expression.
A watchpoint stops execution of your program whenever the value of
an expression is either read or written.
Valgrind je vynikajúci nástroj. Vyskúšaj.
8.12.2010 14:29 Franta Hanzlík
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
$ nm terminal.o |grep using_xterm 00000e90 T using_xterm

Překládané to asi je, žádný #ifdef se toho asi netýká.

"valgrind --leak-check=yes --log-file=v /usr/bin/dosemu.bin":

Na PC kde program fungoval funguje i teď, valgrind vytvoří asi 13kB log, na konci jsou sice nějaká hlášení o leacích, ale asi ne příliš podstatná:
==6935== HEAP SUMMARY:
==6935==     in use at exit: 38,675 bytes in 49 blocks
==6935==   total heap usage: 1,818 allocs, 1,769 frees, 194,819 bytes allocated
==6935== 
==6935== LEAK SUMMARY:
==6935==    definitely lost: 0 bytes in 0 blocks
==6935==    indirectly lost: 0 bytes in 0 blocks
==6935==      possibly lost: 0 bytes in 0 blocks
==6935==    still reachable: 38,675 bytes in 49 blocks
==6935==         suppressed: 0 bytes in 0 blocks
==6935== Reachable blocks (those to which a pointer was found) are not shown.
==6935== To see them, rerun with: --leak-check=full --show-reachable=yes
==6935== 
==6935== For counts of detected and suppressed errors, rerun with: -v
==6935== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 18 from 8)
==6935== 
==6935== HEAP SUMMARY:
==6935==     in use at exit: 423,807 bytes in 508 blocks
==6935==   total heap usage: 4,166 allocs, 3,658 frees, 11,417,093 bytes allocated
==6935== 
==6935== 12 bytes in 1 blocks are definitely lost in loss record 34 of 131
==6935==    at 0x400677E: malloc (vg_replace_malloc.c:195)
==6935==    by 0xDF9353: XcursorTryShapeCursor (in /usr/lib/libXcursor.so.1.0.2)
==6935==    by 0x4475CAC: XCreateGlyphCursor (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0x4011A89: X_init (X.c:2426)
==6935==    by 0x80E5296: iodev_init (in /usr/bin/dosemu.bin)
==6935==    by 0x805E334: main (in /usr/bin/dosemu.bin)
==6935== 
==6935== 124 bytes in 1 blocks are definitely lost in loss record 90 of 131
==6935==    at 0x400677E: malloc (vg_replace_malloc.c:195)
==6935==    by 0xB98D83: ??? (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0xB98E3A: ??? (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0xB986F9: xcb_connect_to_display_with_auth_info (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0xB98A2C: xcb_connect (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0x44A0302: _XConnectXCB (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0x4487F62: XOpenDisplay (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0x4011203: X_init (X.c:510)
==6935==    by 0x80E5296: iodev_init (in /usr/bin/dosemu.bin)
==6935==    by 0x805E334: main (in /usr/bin/dosemu.bin)
==6935== 
==6935== 124 bytes in 1 blocks are definitely lost in loss record 91 of 131
==6935==    at 0x400677E: malloc (vg_replace_malloc.c:195)
==6935==    by 0xB98D83: ??? (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0xB98E3A: ??? (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0xB986F9: xcb_connect_to_display_with_auth_info (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0xB98A2C: xcb_connect (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0x44A0302: _XConnectXCB (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0x4487F62: XOpenDisplay (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0x4015895: X11_DetectLayout (X_keymaps.c:73)
==6935==    by 0x813127E: setup_default_keytable (in /usr/bin/dosemu.bin)
==6935==    by 0x812F63B: keyb_server_init (in /usr/bin/dosemu.bin)
==6935==    by 0x81326BA: keyb_init (in /usr/bin/dosemu.bin)
==6935==    by 0x80E5296: iodev_init (in /usr/bin/dosemu.bin)
==6935== 
==6935== 2,000 (80 direct, 1,920 indirect) bytes in 1 blocks are definitely lost in loss record 120 of 131
==6935==    at 0x400677E: malloc (vg_replace_malloc.c:195)
==6935==    by 0x4479193: ??? (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0x4479C97: XQueryFont (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0xDF92D8: XcursorTryShapeCursor (in /usr/lib/libXcursor.so.1.0.2)
==6935==    by 0x4475CAC: XCreateGlyphCursor (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0x4011A89: X_init (X.c:2426)
==6935==    by 0x80E5296: iodev_init (in /usr/bin/dosemu.bin)
==6935==    by 0x805E334: main (in /usr/bin/dosemu.bin)
==6935== 
==6935== LEAK SUMMARY:
==6935==    definitely lost: 340 bytes in 4 blocks
==6935==    indirectly lost: 1,920 bytes in 2 blocks
==6935==      possibly lost: 0 bytes in 0 blocks
==6935==    still reachable: 421,547 bytes in 502 blocks
==6935==         suppressed: 0 bytes in 0 blocks
==6935== Reachable blocks (those to which a pointer was found) are not shown.
==6935== To see them, rerun with: --leak-check=full --show-reachable=yes
==6935== 
==6935== For counts of detected and suppressed errors, rerun with: -v
==6935== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 29 from 10)
Na PC kde hází SEGV se to chová jinak: do logu se zapíše cca 10kB, zdá se shodných jako na OK PC. A pak zřejmě někde cyklí, valgrind (na top-u se zobrazuje memcheck-x86-li(nux)) neustále spotřebovává 95-100% CPU a nic se neděje. Když po několika desítkách minut zkusím breaknout s CTRL/C, skončí to zase na SEGV a valgrin do logu dopíše asi 1600 Byte, tu část od "Process terminating with default action of signal 11":
==10135== 
==10135== HEAP SUMMARY:
==10135==     in use at exit: 38,675 bytes in 49 blocks
==10135==   total heap usage: 1,818 allocs, 1,769 frees, 185,163 bytes allocated
==10135== 
==10135== LEAK SUMMARY:
==10135==    definitely lost: 0 bytes in 0 blocks
==10135==    indirectly lost: 0 bytes in 0 blocks
==10135==      possibly lost: 0 bytes in 0 blocks
==10135==    still reachable: 38,675 bytes in 49 blocks
==10135==         suppressed: 0 bytes in 0 blocks
==10135== Reachable blocks (those to which a pointer was found) are not shown.
==10135== To see them, rerun with: --leak-check=full --show-reachable=yes
==10135== 
==10135== For counts of detected and suppressed errors, rerun with: -v
==10135== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 18 from 8)
==10135== 
==10135== Process terminating with default action of signal 11 (SIGSEGV)
==10135==  Bad permissions for mapped region at address 0x4001245
==10135==    at 0x10C630: _dl_lookup_symbol_x (dl-lookup.c:713)
==10135==    by 0x1174EF: _dl_runtime_resolve (dl-trampoline.S:37)
==10135==    by 0x1FE457: mmap (mmap.S:62)
==10135==    by 0x808E635: remove_from_io_select (dosemu_debug.h:188)
==10135==    by 0x808DAB9: ??? (mapfile.c:208)
==10135==    by 0x80E4FB9: low_mem_init (unistd.h:45)
==10135==    by 0x805E2D4: redraw_cursor (text.c:180)
==10135==    by 0x13CE15: (below main) (libc-start.c:226)
==10135== 
==10135== HEAP SUMMARY:
==10135==     in use at exit: 95,850 bytes in 492 blocks
==10135==   total heap usage: 1,938 allocs, 1,446 frees, 279,383 bytes allocated
==10135== 
==10135== LEAK SUMMARY:
==10135==    definitely lost: 0 bytes in 0 blocks
==10135==    indirectly lost: 0 bytes in 0 blocks
==10135==      possibly lost: 0 bytes in 0 blocks
==10135==    still reachable: 95,850 bytes in 492 blocks
==10135==         suppressed: 0 bytes in 0 blocks
==10135== Reachable blocks (those to which a pointer was found) are not shown.
==10135== To see them, rerun with: --leak-check=full --show-reachable=yes
==10135== 
==10135== For counts of detected and suppressed errors, rerun with: -v
==10135== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 10)
Ten kousek:
==10135==  Bad permissions for mapped region at address 0x4001245
==10135==    at 0x10C630: _dl_lookup_symbol_x (dl-lookup.c:713)
==10135==    by 0x1174EF: _dl_runtime_resolve (dl-trampoline.S:37)
==10135==    by 0x1FE457: mmap (mmap.S:62)
==10135==    by 0x808E635: remove_from_io_select (dosemu_debug.h:188)
==10135==    by 0x808DAB9: ??? (mapfile.c:208)
==10135==    by 0x80E4FB9: low_mem_init (unistd.h:45)
==10135==    by 0x805E2D4: redraw_cursor (text.c:180)
==10135==    by 0x13CE15: (below main) (libc-start.c:226)
je zajímavý, ale jak jej interpretovat?
14.12.2010 09:46 l4m4
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
Chce to asi zjistit, kde se vzala ta oblast paměti na 0x4001245, pak možná bude vidět, proč má špatná práva.

U běžícího procesu se lze podívat do /proc/$PID/maps, u zdechlého to snad GDB taky umí, ale nevím jak.
14.12.2010 11:24 rastos | skóre: 60 | blog: rastos
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
u zdechlého to snad GDB taky umí, ale nevím jak.
Cez ulimit povoliť vytváranie "core" súboru (nejak sa stalo zvykom to zakazovať). A potom v gdb povedať, že má použiť ten core súbor.

Franta: pokiaľ si spokojný z riešením od Voty, tak ho označ ako riešenie.
14.12.2010 11:52 Franta Hanzlík
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
Ahoj, díky za pomoc a omlouvám se za amatérské dotazy. Co se týká toho "Bad permissions for mapped region", nemohlo to pojít od toho, že program na několik svých oblastí předtím volal mprotect() včetně PROT_NONE a že pokud nemají stránky default permissions tak se to valgrindu nelíbí?

Neprogramuji, a tak asi do toho nebudu dál šťourat, to bych musel začít tvrdě od základů; Votovo řešení je dostačující. Ale - jak jej mám označit za řešení? Není to funkce povolená jen registrovaným? Nebo jsem nějaký čudlík přehlédl?
14.12.2010 22:00 rastos | skóre: 60 | blog: rastos
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
omlouvám se za amatérské dotazy.
Nie je na to najmenší dôvod.
pokud nemají stránky default permissions tak se to valgrindu nelíbí
Zjavne valgrind vie o mprotect()-e pretože ho podľa zoznamu opravených bugov valgrindu "nejak" ošetruje. Ale či mu to vadí, to netuším.
Ale - jak jej mám označit za řešení? Není to funkce povolená jen registrovaným?
Aha. To máš pravdu ;-)
8.12.2010 15:25 rastos | skóre: 60 | blog: rastos
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
A pak zřejmě někde cyklí, valgrind (na top-u se zobrazuje memcheck-x86-li(nux)) neustále spotřebovává 95-100% CPU a nic se neděje.
To je normálne. Dnes som bežal pod valgrindom program takmer 20 minút, zatiaľ čo bez neho to trvá pod 15 sekúnd. Cieľom je dostať z valgrindu napr. informácie o použití neinicializovaných premenných alebo iné potenciálne zdroje problémov.

Tak ako vravel Michal - podľa toho backtrace-u to vyzerá, že sa tá funkcia hľadá v dynamickej knižnici, ale ty si správne interpretoval to "T", že tá funkcia má skutočne implementáciu (teda svoj "text") v terminal.o. Potom ma ešte napadá, že to terminal.o sa nedostane do tej zdieľanej knižnice, alebo že sa dokonca použije úplne iná knižnica. Môžeš to nm skúsiť nechať zbehnúť na príslušnú knižnicu/exe. Alebo môžeš sledovať, ktoré knižnice to vlastne použije - to môže prezradiť ldd, alebo (ak sa to dá stihnúť) obsah súboru /proc/{pid}/maps.
13.12.2010 16:55 Franta Hanzlík
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
prdlajs jsem správně interpretoval ;), jen jsem sem pastnul výpis "nm" podle vašeho návodu. Jinak tápu a uvítám další popostrčení. Těch dynamicky loadovaných pluginů jsem se zbavil a překládám je inline (viz jak jsem psal před chvílí výše, padá to stejně i když trochu jinde). Co znamená to "nm nechať zbehnúť na príslušnú knižnicu/exe"? S tím valgrindem jsem také neúspěšný - nechal jsem to běžet přes dvě hodiny, CPU pořád na 100% (naštěstí jen jedno jádro) a kromě oněch cca 10kB jak jsem psal minule už nevypíše nic. Přitom za normálních okolností by měl vytvořit během vteřiny dialogové okno a čekat na uživatelův vstup. ldd na binárku vypíše:
$ ldd /usr/bin/dosemu.bin
	linux-gate.so.1 =>  (0x005b5000)
	libvga.so.1 => /usr/lib/libvga.so.1 (0x0034f000)
	librt.so.1 => /lib/librt.so.1 (0x00343000)
	libdl.so.2 => /lib/libdl.so.2 (0x002bc000)
	libm.so.6 => /lib/libm.so.6 (0x002e1000)
	libslang.so.2 => /usr/lib/libslang.so.2 (0x0077f000)
	libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x059c6000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0x00653000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0x00124000)
	libgpm.so.2 => /usr/lib/libgpm.so.2 (0x005fa000)
	libasound.so.2 => /lib/libasound.so.2 (0x06699000)
	libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0x05b7c000)
	libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x0693d000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x002c3000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00324000)
	libc.so.6 => /lib/libc.so.6 (0x003f1000)
	/lib/ld-linux.so.2 (0x00102000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0x0025b000)
	libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0x068fe000)
	libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x06786000)
	libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x0644a000)
	libogg.so.0 => /usr/lib/libogg.so.0 (0x06442000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0x005f5000)

nic podezřelého na tom taky nevidím. Nemůže to havarovat někde v glibc syscall rutinách? Napadlo mne i zda si třeba přes ten mprotect() nezakáže (třeba blbým parametrem/voláním) přístup k systémovým voláním a pokus o ně pak neskončí takhle, ale nevím jak to ověřit nebo vyloučit.
Keby som mal pušku...
Ale takhle?
14.12.2010 12:12 Jirka P
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
Napadlo mne i zda si třeba přes ten mprotect() nezakáže (třeba blbým parametrem/voláním)
Jestli chcete zjistit, co se děje s mapováními, zkuste si přečíst /proc/$PID/maps a použijte strace na ten program.
13.12.2010 12:39 asi si ten profil uz vazne zalozim
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
Jen tak strelim od boku, treba to pomuze. Pokud to buildite pomoci gcc, zkuste pridat prepinac -rdynamic
13.12.2010 17:04 Franta Hanzlík
Rozbalit Rozbalit vše Re: program padá na SIGSEGV, jak odladit?
Jojo, s gcc. Ale pokud to konfiguruji s dynamicky překládanými pluginy, tak se (asi) vše sestavuje s -rdynamic. Teď když je mám inline, tak ne - ale jak píši výše, problém bude asi někde jinde.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.