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í
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 00:10 | Nová verze

Byla vydána verze 4.7 redakčního systému WordPress. Kódové označením Vaughan bylo vybráno na počest americké jazzové zpěvačky Sarah "Sassy" Vaughan. Z novinek lze zmínit například novou výchozí šablonu Twenty Seventeen, náhledy pdf souborů nebo WordPress REST API.

Ladislav Hagara | Komentářů: 0
včera 12:00 | Zajímavý projekt

Projekt Termbox umožňuje vyzkoušet si linuxové distribuce Ubuntu, Debian, Fedora, CentOS a Arch Linux ve webovém prohlížeči. Řešení je postaveno na projektu HyperContainer. Podrobnosti v často kladených dotazech (FAQ). Zdrojové kódy jsou k dispozici na GitHubu [reddit].

Ladislav Hagara | Komentářů: 13
včera 11:00 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2016-8655 v Linuxu zneužitelné k lokální eskalaci práv. Chyba se dostala do linuxového jádra v srpnu 2011. V upstreamu byla opravena minulý týden [Hacker News].

Ladislav Hagara | Komentářů: 1
5.12. 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

Ladislav Hagara | Komentářů: 5
5.12. 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

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

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 10
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 17
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 26
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 18
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 777 hlasů
 Komentářů: 50, poslední 29.11. 15:50
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: 1308×
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.