[ LUGOS ] RH 5.0 in buggy buggy libi

[Timotej Ecimovic - Cic]

Hi!

> 
> Zadeva naredi nekaj htmljev BP, nato pa se ustavi pri kakem fopen; gdb
> izplune:
> 
> Program received signal SIGSEGV, Segmentation fault. 
> 0x4004be18 in chunk_free () at malloc.c:2821 
> 
> malloc.c je (afaik) modul glibcja, vrstica, ki jo izvaja pa
> fl=fopen("/html/myfile.html", "a"); // recimo
> 
> Na RH 3.0.3, RH 4.0 ter Slacku 3.1 dela zadeva BP, z isto bazo
> (msqldump).
> 
> Jaz sem ze izgubil zivne in "upgradeam" na Debian. Upam da tam ne bo
> problemov. Je kdo kaj podobnega zasledil?
> 

Jaz sem v zivljenju tam nekje 4-5-krat ze obtozil sistemske knjiznice,
da so pokvarjene. Najbolj vneto takrat, ko mi je program dumpal core na
vrstici:
  fprintf ( stderr, "A tole zdej dela al ne?!?!\n" );

V vseh primerih je zadeva delala recimo na AIX in HPUX, na Linuxu pa ne,
ali pa kaksna drugacna kombinacija UNIXov od katerih je na nekaterih delalo,
na nekaterih ni delalo, na katerih pa vcasih delalo.

Na koncu sem v vedno moral priznati premoc sistemu in skruseno
poloviti lastne buge, ki so bili pogosto precej zviti. A si probal kaksen
electric-fence ali podobno zadevo za debuggat malloc()/free() probleme?

Cic, 
  ki ima zelo slabe izkusnje z obtozevanjem sistemskih knjiznic, da so
  buggy in to ponavadi ne naredi iz razum a temvec iz obupa.

PS: fprintf() se je usuval zato, ker je program nakje dalec prej iz zelo
trapastega in tezko najdljivega razloga povozil zakljucni \0 v staticnem
stringu od fprintf()-a. Ta je potem dumpal core, ker ni in ni prisel
do konca stringa znotraj sebi dostopnega spomina. Zadeva pa je na
nekaterih platformah delala, ker so kompajlerji drugace pozlozili
staticne stringe in povozenih nekaj bajtov ni bilo esencialnih za
nadaljne delovanje, torej sploh nisem opazil, da je bilo kaj narobe.