🚀 go-pugleaf

Może jeszcze dodam, że funkcja
function tCurl.Perform:boolean;
znajduje się w module curlobj.
Wywołuje ona funkcję
function tCurl.DoPerform(aCurl:pCurl):CurlCode;
(źródło w pliku ocurlthd.inc)
w której jest pętla while:

       while (fBusy) do begin //Zapetla sie po 300 wywolaniach
         usleep(fWaitInterval * 1000); //w tym czasie fBusy powinno
                                       //byc juz false, a nie jest
         if Assigned(fOnWait) and ( {$IFNDEF FPC}@{$ENDIF}fOnWait <> nil 
) then begin
           pthread_mutex_lock(fMutex);
           fOnWait(self);
           pthread_mutex_unlock(fMutex);
         end else if Assigned(fWaitCallback) and ( {$IFNDEF 
FPC}@{$ENDIF}fWaitCallback <> nil ) then begin
           pthread_mutex_lock(fMutex);
           fWaitCallback(fWaitData);
           pthread_mutex_unlock(fMutex);
         end;
       end;

Doszedłem już do tego, że zmienna fBusy po 300 wywołaniach
ma cały czas wartość True i nie chce się zmienić na False,
stąd robi się nieskończona pętla.
Pytanie tylko dlaczego? Tu niestety utknąłem w analizie
problemu :(

Sławek

Może jeszcze dodam, że funkcja
function tCurl.Perform:boolean;
znajduje się w module curlobj.
Wywołuje ona funkcję
function tCurl.DoPerform(aCurl:pCurl):CurlCode;
(źródło w pliku ocurlthd.inc)
w której jest pętla while:

      fBusy:=True;
     {$IFDEF WIN32}
       //dla windows - wycialem
     {$ELSE WIN32}
       pthread_mutex_init({$IFDEF FPC}@{$ENDIF}fMutex, nil);
       pthread_create({$IFDEF FPC}@{$ENDIF}fThread, nil, {$IFDEF 
FPC}@{$ENDIF}CurlThreadExecute, self);
      while (fBusy) do begin //Zapetla sie po 300 wywolaniach
         usleep(fWaitInterval * 1000); //w tym czasie fBusy powinno
                                       //byc juz false, a nie jest
         if Assigned(fOnWait) and ( {$IFNDEF FPC}@{$ENDIF}fOnWait <> nil 
) then begin
           pthread_mutex_lock(fMutex);
           fOnWait(self);
           pthread_mutex_unlock(fMutex);
         end else if Assigned(fWaitCallback) and ( {$IFNDEF 
FPC}@{$ENDIF}fWaitCallback <> nil ) then begin
           pthread_mutex_lock(fMutex);
           fWaitCallback(fWaitData);
           pthread_mutex_unlock(fMutex);
         end;
       end;

Doszedłem już do tego, że zmienna fBusy po 300 wywołaniach
ma cały czas wartość True i nie chce się zmienić na False,
stąd robi się nieskończona pętla.
Pytanie tylko dlaczego? Tu niestety utknąłem w analizie
problemu :(

Sławek

Tutaj tworzony jest wątek CurlThreadExecute
>       pthread_mutex_init({$IFDEF FPC}@{$ENDIF}fMutex, nil);
>       pthread_create({$IFDEF FPC}@{$ENDIF}fThread, nil, {$IFDEF 
> FPC}@{$ENDIF}CurlThreadExecute, self);

<code>
   function CurlThreadExecute(o:pointer):LongInt; cdecl;
   begin
     with TCurl(o) do begin
       fThdResult:=curl_easy_perform(fCurl);
       fBusy:=False;
     end;
     Result:=0;
   end;
</code>

Wygląda na to, że po 300-stu wywołaniach przestaje się ten wątek
wykonywać, dlatego zmienna fBusy pozostaje z wartością True.
Tylko dlaczego tak się dzieje?
Stała PTHREAD_THREADS_MAX = 1024.
Być może wątki nie są poprawnie zakończone i zachowują się jak zombi.
Aczkolwiek całość zakończona jest procedurą:
pthread_mutex_destroy({$IFDEF FPC}@{$ENDIF}fMutex);
Tylko jak sprawdzić, czy ilość utworzonych wątków doszła do 1024?
Jak sprawdzić ile ich jest?

Sławek

Terrmit wrote:
> Wygląda na to, że po 300-stu wywołaniach przestaje się ten wątek
> wykonywać, dlatego zmienna fBusy pozostaje z wartością True.
> Tylko dlaczego tak się dzieje?
> Stała PTHREAD_THREADS_MAX = 1024.
> Być może wątki nie są poprawnie zakończone i zachowują się jak zombi.
> Aczkolwiek całość zakończona jest procedurą:
> pthread_mutex_destroy({$IFDEF FPC}@{$ENDIF}fMutex);
> Tylko jak sprawdzić, czy ilość utworzonych wątków doszła do 1024?
> Jak sprawdzić ile ich jest?


Pokaż lepiej kompilowalny proof-of-concept konsolowy, bez żadnych
za przeproszeniem TForm ;-).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Łukasz 'Maly' Ostrowski pisze:
> Terrmit wrote:
[ciach]
> 
> Pokaż lepiej kompilowalny proof-of-concept konsolowy, bez żadnych
> za przeproszeniem TForm ;-).
> 
Program jest okienkowy, to i kod okienkowy.
Nie bardzo chce mi się kombinować żeby przerabiać to na konsolę,
tym bardziej, że ostatni konsolowy program pisałem 10 lat temu.
Ale przynajmniej dziękuję za zainteresowanie.

Solaris 'objechał' mnie kiedyś, że libcurl to taka świetna
biblioteka, a ja nie chcę z niej skorzystać. W końcu skorzystałem,
to teraz okazuje się, że jest jakiś babol. Co prawda, nie korzystam
bezpośrednio z libcurl (bo ni cholery nie wiem jak jej użyć w pascalu),
ale za pośrednictwem curlpas, który wydawał się całkiem przyjazny,
aż do chwili, gdy oparłem się o granicę tych 300 witryn.

A może Pan Solaris dostrzeże to wołanie o pomoc i podpowie jak
pobrać źródło strony do MemoryStream bezpośrednio za pomocą libcurl?

Sławek

Terrmit pisze:
> Tutaj tworzony jest wątek CurlThreadExecute
>>       pthread_mutex_init({$IFDEF FPC}@{$ENDIF}fMutex, nil);
>>       pthread_create({$IFDEF FPC}@{$ENDIF}fThread, nil, {$IFDEF 
>> FPC}@{$ENDIF}CurlThreadExecute, self);

Kolejna wskazówka.
Po 300 wywołaniach (ale czasami po 301, a nawet po 302)
funkcja pthread_create zwraca kod 12 (ENOMEM), czyli
brak pamięci. Czyżby to oznaczało, że wątki nie są kończone
i zjadają pamięć?

Dopisałem pthread_exit(nil) na końcu wątku, ale to nic nie dało :(
> <code>
>   function CurlThreadExecute(o:pointer):LongInt; cdecl;
>   begin
>     with TCurl(o) do begin
>       fThdResult:=curl_easy_perform(fCurl);
>       fBusy:=False;
>     end;
>     Result:=0;
     pthread_exit(nil);
>   end;
> </code>
> 

Może jednaj ktoś wpadnie na pomysł, co tu szwankuje?

Sławek

Terrmit pisze:
> Terrmit pisze:
>> Tutaj tworzony jest wątek CurlThreadExecute
>>>       pthread_mutex_init({$IFDEF FPC}@{$ENDIF}fMutex, nil);
>>>       pthread_create({$IFDEF FPC}@{$ENDIF}fThread, nil, {$IFDEF 
>>> FPC}@{$ENDIF}CurlThreadExecute, self);
> 
> Kolejna wskazówka.
> Po 300 wywołaniach (ale czasami po 301, a nawet po 302)
> funkcja pthread_create zwraca kod 12 (ENOMEM), czyli
> brak pamięci. Czyżby to oznaczało, że wątki nie są kończone
> i zjadają pamięć?
> 

Znalazłem artykuł Mirosława Jedynaka o wątkach w Linuksie:
http://www.g2inf.one.pl/referaty/watki-referat.pdf
<cytat>
W momencie, gdy watek w stanie umożliwiającym dołączenie kończy
działanie jego zasoby (deskryptor wątku i stos) *nie są zwalniane*
dopóki inny watek nie wykona na nim pthread_join. Dlatego
pthread_join powinien być wykonany dla każdego nieodłączonego wątku.
</cytat>
I rzeczywiście. Wstawiłem tą funkcję na końcu procedury, gdzie
wątek nie powinien się już wykonywać. Pomogło!
Ale akapit wcześniej autor napisał, że:
<cytat>
Watek, do którego dołączamy musi być w stanie umożliwiającym dołączanie
(nie może być odłączony przez wywołanie pthread_detach [...]
</cytat>
Czyli chyba lepiej, gdy zaraz po utworzeniu wątku przez pthread_create,
zrobi się go wątkiem odłączonym. Wtedy po zakończeniu wątku jego
deskryptor i stos powinny być zwolnione.
       pthread_detach(fThread);

Wydaje się, że to powinno pomóc. Chyba, że jest jeszcze inne lepsze
rozwiązanie tego problemu?

Sławek

Terrmit pisze:
> Terrmit pisze:
>> Tutaj tworzony jest wątek CurlThreadExecute
>>>       pthread_mutex_init({$IFDEF FPC}@{$ENDIF}fMutex, nil);
>>>       pthread_create({$IFDEF FPC}@{$ENDIF}fThread, nil, {$IFDEF 
>>> FPC}@{$ENDIF}CurlThreadExecute, self);
> 
> Kolejna wskazówka.
> Po 300 wywołaniach (ale czasami po 301, a nawet po 302)
> funkcja pthread_create zwraca kod 12 (ENOMEM), czyli
> brak pamięci. Czyżby to oznaczało, że wątki nie są kończone
> i zjadają pamięć?
> 

Znalazłem artykuł Mirosława Jedynaka o wątkach w Linuksie:
http://www.g2inf.one.pl/referaty/watki-referat.pdf
<cytat>
W momencie, gdy watek w stanie umożliwiającym dołączenie kończy
działanie jego zasoby (deskryptor wątku i stos) *nie są zwalniane*
dopóki inny watek nie wykona na nim pthread_join. Dlatego
pthread_join powinien być wykonany dla każdego nieodłączonego wątku.
</cytat>
I rzeczywiście. Wstawiłem tą funkcję na końcu procedury, gdzie
wątek nie powinien się już wykonywać. Pomogło!
Ale akapit wcześniej autor napisał, że:
<cytat>
Watek, do którego dołączamy musi być w stanie umożliwiającym dołączanie
(nie może być odłączony przez wywołanie pthread_detach [...]
</cytat>
Czyli chyba lepiej, gdy zaraz po utworzeniu wątku przez pthread_create,
zrobi się go wątkiem odłączonym. Wtedy po zakończeniu wątku jego
deskryptor i stos powinny być zwolnione.
       pthread_detach(fThread);

Wydaje się, że to powinno pomóc. Chyba, że jest jeszcze inne lepsze
rozwiązanie tego problemu?

Sławek

Terrmit pisze:
> Terrmit pisze:
>> Tutaj tworzony jest wątek CurlThreadExecute
>>>       pthread_mutex_init({$IFDEF FPC}@{$ENDIF}fMutex, nil);
>>>       pthread_create({$IFDEF FPC}@{$ENDIF}fThread, nil, {$IFDEF 
>>> FPC}@{$ENDIF}CurlThreadExecute, self);
> 
> Kolejna wskazówka.
> Po 300 wywołaniach (ale czasami po 301, a nawet po 302)
> funkcja pthread_create zwraca kod 12 (ENOMEM), czyli
> brak pamięci. Czyżby to oznaczało, że wątki nie są kończone
> i zjadają pamięć?
> 
Znalazłem artykuł Mirosława Jedynaka o wątkach w Linuksie:
http://www.g2inf.one.pl/referaty/watki-referat.pdf
<cytat>
W momencie, gdy watek w stanie umożliwiającym dołączenie kończy
działanie jego zasoby (deskryptor wątku i stos) *nie są zwalniane*
dopóki inny watek nie wykona na nim pthread_join. Dlatego
pthread_join powinien być wykonany dla każdego nieodłączonego wątku.
</cytat>
I rzeczywiście. Wstawiłem tą funkcję na końcu procedury, gdzie
wątek nie powinien się już wykonywać. Pomogło!
Ale akapit wcześniej autor napisał, że:
<cytat>
Watek, do którego dołączamy musi być w stanie umożliwiającym dołączanie
(nie może być odłączony przez wywołanie pthread_detach [...]
</cytat>
To drugi sposób, chyba lepszy, gdy zaraz po utworzeniu wątku przez
pthread_create, zrobi się go wątkiem odłączonym. Wtedy po zakończeniu
wątku jego deskryptor i stos powinny być zwolnione.
       pthread_detach(fThread);

Wydaje się, że to też działa. Chyba, że jest jeszcze inne lepsze
rozwiązanie tego problemu?

Sławek

Dzięki stary!
Wszystko na razie działa jak należy :)

Sławek

Terrmit pisze:
> Dzięki stary!
> Wszystko na razie działa jak należy :)
> 
> Sławek
Ależ proszę bardzo :)

Terrmit wrote:
> Terrmit pisze:
>> Dzięki stary!
>> Wszystko na razie działa jak należy :)
>>
>> Sławek
> Ależ proszę bardzo :)


Muehehe ;-). Gratulacje Wam obu w rozwiązaniu tego problemu X-D.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Łukasz 'Maly' Ostrowski pisze:
[ciach]
> Muehehe ;-). Gratulacje Wam obu w rozwiązaniu tego problemu X-D.
> 
Skoro nikt się nie przyłączył do dyskusji, to musieliśmy sobie
sami jakoś poradzić :)

A tak na poważnie, to nie ma tu nikogo, kto by w pascalu
używał curl do pobierania stron internetowych, albo do ftp?

Sławek

Terrmit wrote:
> Łukasz 'Maly' Ostrowski pisze:
> [ciach]
>> Muehehe ;-). Gratulacje Wam obu w rozwiązaniu tego problemu X-D.
>>
> Skoro nikt się nie przyłączył do dyskusji, to musieliśmy sobie
> sami jakoś poradzić :)
>
> A tak na poważnie, to nie ma tu nikogo, kto by w pascalu
> używał curl do pobierania stron internetowych, albo do ftp?


Ja za curl nie przepadam bo ma API niczym orginalny
curl dla NAZI C ;-).

Swoje rzeczy zaciągałem swojego czasu jeszcze bardziej
poronionym WinInet.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Łukasz 'Maly' Ostrowski pisze:
[ciach]
> 
> Ja za curl nie przepadam bo ma API niczym orginalny
> curl dla NAZI C ;-).
Zgadza się, ale biblioteka curlpas daje całkiem fajny
komponent TCurl, który pozwala korzystać z biblioteki
curl całkiem przyjemnie. Tylko rozwój curlpas jakoś
zatrzymał się w czasie, szczerze mówiąc nie wiem dlaczego.
http://sourceforge.net/projects/curlpas
Czyżby istniały we freepascalu inne lepsze rozwiązania,
a ja o nich nic nie wiem?
> 
> Swoje rzeczy zaciągałem swojego czasu jeszcze bardziej
> poronionym WinInet.
> 
Wcześniej używałem Indy, ale to kombajn i kabyła,
i też były z nim problemy.
Staram się używać jak najmniej zewnętrznych komponentów,
bo nadmiernie rozpychają program. Lazarus i tak generuje
dość duży plik wykonywalny.

Sławek

Terrmit wrote:
> Staram się używać jak najmniej zewnętrznych komponentów,
> bo nadmiernie rozpychają program. Lazarus i tak generuje
> dość duży plik wykonywalny.


Duży? To chyba mało powiedziane, AFAIR ostatnio jak
korzystałem z lazarusa to pusty projekt dawał mi
6mb exeka ~=].

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Dnia Sun, 6 Apr 2008 11:59:09 +0200, jakże pięknego
Łukasz 'Maly' Ostrowski <maly@USUNnemo.pl> wystukał co zawarte poniżej:

: Terrmit wrote:
: > Staram się używać jak najmniej zewnętrznych komponentów,
: > bo nadmiernie rozpychają program. Lazarus i tak generuje
: > dość duży plik wykonywalny.
: 
: 
: Duży? To chyba mało powiedziane, AFAIR ostatnio jak
: korzystałem z lazarusa to pusty projekt dawał mi
: 6mb exeka ~=].

A co to jest 6M przy dzisiejszych dyskach? ;)

-- 
Home: admin.idns.pl (fajek.sytes.net)
Linux registered user: 408584
Contact: GG#44450, solaris#idns.pl
19:16:28 -!- Platyna Erroneous Nickname 

Witam,

Nie no wymiękam już :(
Chyba zaczynam rozumieć dlaczego moduł curlpas został porzucony.
Wszystko pięknie działało, a teraz muszę wysłać formularz,
taki dość duży, a w tym plik graficzny. Metoda POST.
Użyłem więc funkcji TCurl.FormData.Add. Za pierwszym razem
poszło, nawet obrazek się uploadował (co za słowo :)).
Niestety za chwilę znów program zaczął mi się wywalać
na tej bibliotece, chociaż nic nie zmieniałem. Magia jakaś.
Wykrzacza się na tej funkcji, co chodzi w wątku:
   function CurlThreadExecute(o:pointer):LongInt; cdecl;
   begin
     with TCurl(o) do begin
       fThdResult:=curl_easy_perform(fCurl); //tu wskazuje błąd
       fBusy:=False;
     end;
     Result:=0;
   end;

Kombinuję z tym od kilku godzin. Nic nie pomaga i nie
mogę dojść w czym rzecz :(

Jak używam TCurl.PostFields do formularza, to idzie,
ale tym się chyba nie da grafiki przesłać. Elementy
formularza dodaję z separatorem '&':
MyCurl.PostFields := 'nazwa1=wartosc1&nazwa2=wartosc2&nazwa3=wartosc3';
Ktoś wie jak w ten sposób dołączyć grafikę?
Gdzieś wyczytałem, żeby dodać małpkę '@' przed nazwą pliku,
w ten sposób:
MyCurl.PostFields := 'nazwa1=wartosc1&nazwa2=wartosc2&nazwa3=wartosc3'+
                      '&'+'@'+'/home/slawek/katalog/plik.gif';
Ale w ten sposób też nie udało mi się załadować obrazka,
chociaż reszta formularza weszła na serwer i program się
nie wywalił.

Sławek :(

Terrmit wrote:
> Witam,
>
> Nie no wymiękam już :(
> Chyba zaczynam rozumieć dlaczego moduł curlpas został porzucony.
> Wszystko pięknie działało, a teraz muszę wysłać formularz,
> taki dość duży, a w tym plik graficzny. Metoda POST.
> Użyłem więc funkcji TCurl.FormData.Add. Za pierwszym razem
> poszło, nawet obrazek się uploadował (co za słowo :)).
> Niestety za chwilę znów program zaczął mi się wywalać
> na tej bibliotece, chociaż nic nie zmieniałem. Magia jakaś.
> Wykrzacza się na tej funkcji, co chodzi w wątku:
>   function CurlThreadExecute(o:pointer):LongInt; cdecl;
>   begin
>     with TCurl(o) do begin
>       fThdResult:=curl_easy_perform(fCurl); //tu wskazuje błąd
>       fBusy:=False;
>     end;
>     Result:=0;
>   end;


Nie wyglada to dość skomplikowanie:

http://curlpas.sourceforge.net/demo/testmpf2.pas.html

I teraz metoda Kopiego i Pasta przerzuć to do siebie.
;-)

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Łukasz 'Maly' Ostrowski pisze:
[ciach]
> 
> Nie wyglada to dość skomplikowanie:
> 
> http://curlpas.sourceforge.net/demo/testmpf2.pas.html
> 
> I teraz metoda Kopiego i Pasta przerzuć to do siebie.
> ;-)
> 
Ależ ja dokładnie taką metodę stosuję z tym, że mnie
interesuje tylko
   MyCurl.FormData.Add( 'whodunit',  'testclient', '',
       POST_TYPE_PLAIN ); // send a string as contents
do przesyłania danych formularzy (teksty z editów i memo)
oraz
   MyCurl.FormData.Add( 'filethis',  'sendme.jpg', 'image/jpeg',
       POST_TYPE_ATTACHMENT );  // send the file itself
pliki jpeg i gif z tym, że dla gifa daję 'image/gif'.

Niby proste, a curl się wywala :(

Terrmit wrote:
> Łukasz 'Maly' Ostrowski pisze:
> [ciach]
>>
>> Nie wyglada to dość skomplikowanie:
>>
>> http://curlpas.sourceforge.net/demo/testmpf2.pas.html
>>
>> I teraz metoda Kopiego i Pasta przerzuć to do siebie.
>> ;-)
>>
> Ależ ja dokładnie taką metodę stosuję z tym, że mnie
> interesuje tylko
>   MyCurl.FormData.Add( 'whodunit',  'testclient', '',
>       POST_TYPE_PLAIN ); // send a string as contents
> do przesyłania danych formularzy (teksty z editów i memo)
> oraz
>   MyCurl.FormData.Add( 'filethis',  'sendme.jpg', 'image/jpeg',
>       POST_TYPE_ATTACHMENT );  // send the file itself
> pliki jpeg i gif z tym, że dla gifa daję 'image/gif'.
>
> Niby proste, a curl się wywala :(


Co to znaczy "wywala"? Exception, jakiś komunikat, cokolwiek?
;-)

- Samochod mi nie działa
- tzn?
- No nie działa
- huh?
- Nie jeździ

;-).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Terrmit pisze:
> Łukasz 'Maly' Ostrowski pisze:
> [ciach]
>>
>> Nie wyglada to dość skomplikowanie:
>>
>> http://curlpas.sourceforge.net/demo/testmpf2.pas.html
>>
>> I teraz metoda Kopiego i Pasta przerzuć to do siebie.
>> ;-)
>>
> Ależ ja dokładnie taką metodę stosuję z tym, że mnie
> interesuje tylko
>   MyCurl.FormData.Add( 'whodunit',  'testclient', '',
>       POST_TYPE_PLAIN ); // send a string as contents
> do przesyłania danych formularzy (teksty z editów i memo)
> oraz
>   MyCurl.FormData.Add( 'filethis',  'sendme.jpg', 'image/jpeg',
>       POST_TYPE_ATTACHMENT );  // send the file itself
> pliki jpeg i gif z tym, że dla gifa daję 'image/gif'.
> 
> Niby proste, a curl się wywala :(
Dostaję
Project raised exception class 'External: SIGSEGV'.
Execution paused
   Adress: $0017112B
   Procedure: strlen
   File:

jak pominę wysyłanie pliku, to reszta idzie na serwer
i błędu nie ma, czyli tylko przy przesyłaniu grafiki
na serwer program się wywala.

Terrmit wrote:
> Dostaję
> Project raised exception class 'External: SIGSEGV'.
> Execution paused
>   Adress: $0017112B
>   Procedure: strlen
>   File:
>
> jak pominę wysyłanie pliku, to reszta idzie na serwer
> i błędu nie ma, czyli tylko przy przesyłaniu grafiki
> na serwer program się wywala.


Skompiluj z debugging info i z line info i połap się
gdzie ten segmentation fault leci.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Łukasz 'Maly' Ostrowski pisze:
> Terrmit wrote:
>> Dostaję
>> Project raised exception class 'External: SIGSEGV'.
>> Execution paused
>>   Adress: $0017112B
>>   Procedure: strlen
>>   File:
>>
>> jak pominę wysyłanie pliku, to reszta idzie na serwer
>> i błędu nie ma, czyli tylko przy przesyłaniu grafiki
>> na serwer program się wywala.
> 
> 
> Skompiluj z debugging info i z line info i połap się
> gdzie ten segmentation fault leci.
> 

Nie jestem pewien, czy właściwe opcje włączyłem, ale
przytoczę fragment z wyjścia debuggera:

[...]
~"[New Thread -1212765296 (LWP 11192)]\n"

~"[Switching to Thread -1212765296 (LWP 11192)]\n"

*stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation 
fault",thread-id="8",frame={addr="0x0017112b",func="strlen",args=[],from="/lib/libc.so.6"}

(gdb)

<-stack-info-depth>
^done,depth="12"

(gdb)

<-stack-list-arguments 1 0 0>
^done,stack-args=[frame={level="0",args=[]}]

(gdb)

<-stack-list-frames 0 0>
^done,stack=[frame={level="0",addr="0x0017112b",func="strlen",from="/lib/libc.so.6"}]

(gdb)

<-stack-list-arguments 1 1 1>
^done,stack-args=[frame={level="1",args=[]}]

(gdb)

<-stack-list-frames 1 1>
^done,stack=[frame={level="1",addr="0xb7fbdf06",func="fread",from="/usr/lib/libcurl.so.4"}]

(gdb)

<-stack-list-arguments 1 2 2>
^done,stack-args=[frame={level="2",args=[]}]

(gdb)

<-stack-list-frames 2 2>
^done,stack=[frame={level="2",addr="0xb7fbf24c",func="curl_mvsnprintf",from="/usr/lib/libcurl.so.4"}]

[...]

Chyba wystarczy. To jest to miejsce, gdzie następuje błąd.
Szczerze mówiąc z obsługi debuggera jestem raczej słaby,
także te komunikaty niewiele mi mówią.
Może Tobie coś więcej podpowiedzą.

Sławek

Łukasz 'Maly' Ostrowski pisze:
> Terrmit wrote:
>> Dostaję
>> Project raised exception class 'External: SIGSEGV'.
>> Execution paused
>>   Adress: $0017112B
>>   Procedure: strlen
>>   File:
>>
>> jak pominę wysyłanie pliku, to reszta idzie na serwer
>> i błędu nie ma, czyli tylko przy przesyłaniu grafiki
>> na serwer program się wywala.
> 
> 
> Skompiluj z debugging info i z line info i połap się
> gdzie ten segmentation fault leci.
> 
Wydaje mi się ponadto, że błąd jest w innym miejscu,
niż miejsce, w którym następuje 'katastrofa'.

Terrmit wrote:
> Wydaje mi się ponadto, że błąd jest w innym miejscu,
> niż miejsce, w którym następuje 'katastrofa'.


Ale to naprowadzić może na to prawdziwe miejsce ;).
Jutro sie postaram do tego spojrzeć, teraz jestem
wykończony, a na rano do roboty.

Pozatym, nie przepadam za nazywaniem GDB
debuggerem ;). Fatalnie się tym operuje...

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/