pdksh nadal "się psuje"...

[Jakub Bogusz]

On Fri, May 11, 2001 at 06:34:26PM +0200, Arkadiusz Miskiewicz wrote:
> On/Dnia Fri, May 11, 2001 at 05:54:21PM +0200, Jakub Bogusz wrote/napisał(a)
> > Wprawdzie nie "core dumped", ale nadal sobie nadpisuje strukturę source.

Przy budowaniu php nadal jest core dumped.

> > Przy budowaniu inna:
> > 
> > ../libtool: nu[4]: test: yes: unexpected operator/operand
> >             ^^
> > ../libtool: L^]^G^H°^N^Y^H^I[0]: test: yes: unexpected operator/operand
> Musimy coś z tym w końcu zrobić... Jak do tej pory nikomu się nie udało namierzyć
> źródła błędu, autor nie odpowiada, a pdksh się sypie...

Na razie udało mi się zauważyć tyle:
- zwiększanie cells w alloc/aresize (to co robią kolejne mutacje patcha
  alloc) powoduje co najwyżej zrzucanie core w innym miejscu...

- php udało się zbudować dopiero po wywaleniu całego własnego
  zarządzania pamięcią i zastąpieniu go przez:

Area *ainit(register Area *ap) { return ap; }
void afreeall(register Area *ap) { return; }
void *alloc(size_t size,register Area *ap) { return malloc(size); }
void *aresize(register void *ptr, size_t size, Area *ap) { return realloc(ptr,size); }
void afree(void *ptr, register Area *ap) { free(ptr); }

  Po tym ksh nie chce zrzucać core[1], także zlinkowany z efence.
  Co nie znaczy, że błędów nie ma.
  (afreeall prawdopodobnie powoduje memory leak - może próbować
  zapisywać do ap wskaźniki i w afreeall zwalniać jeszcze nie zwolnione
  - może to by ujawniło jakieś błędy)

- sam komunikat "test: {yes|no}: enexpected operator/operand" nie podoba
  mi się - nie tyle jego występowanie[2], co treść - albo w ogóle bez
  numeru linii, albo z numerem linii wziętym z sufitu (np. wskazującym
  na linię o treści 'fi # test -z "$show_help"', podczas gdy pod gdb
  w strukturach można znaleźć prawdziwą informację.
  
  [2] występuje przy np. "test = no" - w skryptach libtoola niektóre zmienne
  nie są ejęte w "" i ich brak powoduje ten komunikat - np. taka linia:
  if test $pic_mode = no && test "$deplibs_check_method" != pass_all; then

- [1] nie licząc próby uruchomienia go jako shella interaktywnego - ale
  tu winny jest błąd w patchu history, który już wyśledziłem i zaraz poprawię.
  Ciekawe, że ten błąd nie wyszedł przed grzebaniem w zarządzaniu pamięcią...

  (a swoją drogą cóż za "wspaniały" pomysł oznaczać pustą historię
  wskaźnikiem równym (wskaźnik_do_początku_historii - 1)  - oczywiście
  wskazującym na bzdury...)


-- 
Jakub Bogusz
http://prioris.mini.pw.edu.pl/~qboosh/