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í
×

24.6. 01:23 | Komunita

Phoronix spustil 2017 Linux Laptop Survey. Tento dotazník s otázkami zaměřenými na parametry ideálního notebooku s Linuxem lze vyplnit do 6. července.

Ladislav Hagara | Komentářů: 2
23.6. 22:44 | Nová verze

Po třech měsících vývoje od vydání verze 5.5.0 byla vydána verze 5.6.0 správce digitálních fotografií digiKam (digiKam Software Collection). Do digiKamu se mimo jiné vrátila HTML galerie a nástroj pro vytváření videa z fotografií. V Bugzille bylo uzavřeno více než 81 záznamů.

Ladislav Hagara | Komentářů: 1
23.6. 17:44 | Nová verze

Byla vydána verze 9.3 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab. Představení nových vlastností v příspěvku na blogu a na YouTube.

Ladislav Hagara | Komentářů: 3
23.6. 13:53 | Nová verze

Simon Long představil na blogu Raspberry Pi novou verzi 2017-06-21 linuxové distribuce Raspbian určené především pro jednodeskové miniaturní počítače Raspberry Pi. Společně s Raspbianem byl aktualizován také instalační nástroj NOOBS (New Out Of the Box Software). Z novinek lze zdůraznit IDE Thonny pro vývoj v programovacím jazyce Python a především offline verzi Scratche 2.0. Ten bylo dosud možné používat pouze online. Offline bylo možné používat pouze Scratch ve verzi 1.4. Z nového Scratchu lze ovládat také GPIO piny. Scratch 2.0 vyžaduje Flash.

Ladislav Hagara | Komentářů: 1
22.6. 14:24 | Nová verze

Opera 46, verze 46.0.2597.26, byla prohlášena za stabilní. Nejnovější verze tohoto webového prohlížeče je postavena na Chromiu 59. Z novinek lze zmínit například podporu APNG (Animated Portable Network Graphics). Přehled novinek pro vývojáře na blogu Dev.Opera. Oznámení o vydání zmiňuje také první televizní reklamu.

Ladislav Hagara | Komentářů: 0
22.6. 13:37 | IT novinky

I čtenáři AbcLinuxu před dvěma lety vyplňovali dotazníky věnované Retro ThinkPadu. Nyní bylo potvrzeno, že iniciativa Retro ThinkPad je stále naživu a Lenovo připravuje speciální edici ThinkPadu jako součást oslav jeho 25. výročí.

Ladislav Hagara | Komentářů: 28
22.6. 10:22 | Komunita

Bylo oznámeno, že frontend a runtime programovacího jazyka D bude začleněn do kolekce kompilátorů GCC (GNU Compiler Collection). Správcem byl ustanoven Iain Buclaw.

Ladislav Hagara | Komentářů: 7
21.6. 18:47 | IT novinky
Bulharská firma Olimex je známá jako výrobce kvalitních mini arm desek, u nichž se snaží být maximálně open source. Kromě velké otevřenosti taktéž zaručují dlouhodobou podporu výroby, což je vítáno ve firemním prostředí. Nyní firma ohlásila ESP32-GATEWAY, malou IoT desku s Wifi, Bluetooth, Ethernetem a 20 GPIO porty za 22EUR. Tato malá deska je ořezanou verzí ESP32-EVB.
Max | Komentářů: 21
21.6. 18:00 | Zajímavý článek

LinuxGizmos (v dubnu loňského roku přejmenován na HackerBoards a v lednu letošního roku zpět na LinuxGizmos) zveřejnil výsledky čtenářské ankety o nejoblíbenější jednodeskový počítač (SBC) v roce 2017. Letos se vybíralo z 98 jednodeskových počítačů (Tabulky Google). Nejoblíbenějšími jednodeskovými počítači v letošním roce jsou Raspberry Pi 3 Model B, Raspberry Pi Zero W a Raspberry Pi 2 Model B.

Ladislav Hagara | Komentářů: 0
21.6. 14:22 | Pozvánky

Ne-konference jOpenSpace 2017 se koná od 13. do 15. října 2017 v hotelu Farma u Pelhřimova. Registrace účastníků je nutná. Více informací na stránkách ne-konference.

Zdenek H. | Komentářů: 0
Chystáte se pořídit CPU AMD Ryzen?
 (6%)
 (31%)
 (1%)
 (9%)
 (44%)
 (9%)
Celkem 837 hlasů
 Komentářů: 65, poslední 1.6. 19:16
    Rozcestník

    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.