[Mono-dev] [Mono-list] Stability problem under linux MDV 2008 Cooker

Petit Eric surfzoid at gmail.com
Sun Jul 13 19:11:02 EDT 2008

I forget two important thing, first is when the "crash/problem" occure
the dll i use to "wrap" the obexftp lib is "broken", i can restart my
prog and do wath i want, i'm never abble to connect to a phone or do
anything else with the object "client" i need to recompil it and then
i'm again able to connect, list folder and get another file since it
break again, it is sound like the object in the backgound_dowork
doesn't freeing some pointer in memory or a GC problem, no ?

Second, Miguel you ask me about a tcpdump or etherall/shark.., with
the compilation of obexftp with debug=5 i have the packet transmit
between phone and PC so i put it here :
this one is : Conect, list root folder, browse to a folder and then
try to get 14
files, the first one was okay but the 13 next was in "broken" state
like i don't use the corect thread where cli is conected .

2008/7/13 Petit Eric <surfzoid at gmail.com>:
> Hi
> Since this long time i always have this problem, so i will try to
> explain it the more clear i can .
> First, in globaly , as we now threat managment is not the same under
> linux and windows.
> I see and don't really know if it is bad or good, under windows when
> you use a BackGroundWorker ( a "second" thread") you are not allowed
> to "interacte" with GUI part.
> Let's say a form with a textbox "TxtBx1" and a backgroundworker "Bck",
> in the event : Bck_DoWork(...), if you say This.TxtBx1.Text = "some
> text"; yu have a exception about invalid interthread operation.
> But under linux you don't have exception !
> Second :
> My prog, CsObexftp : http://cs-obexftp.wiki.sourceforge.net/ is a tool
> who use the "new" C# binding of obexftp :
> http://dev.zuckschwerdt.org/openobex/ the popular console programme we
> see in most linux OS.
> The work of csobexftp is to conect to a device like a mobile phone by
> Bluetooth, usb or irda and use obex protocole to transfert files.
> So i write csobexftp with 3 backgroundworker , one for conection
> (BckConnect), one for read operation like download or list file
> (BckRead) and a last to write like uploat/put file or make dir
> (BckWrite).
> As we know A Windows Form App have 2 thread, one for the graphical
> part other for the code with the 3 mine (Bck) we have 5 thread.
> The main compnent of the obexftp C# binding is "client", so in global
> declaration i declare one : Client Cli = null;
> Cli is in the thread 2 (code)
> When user click on conect, i start the BckConnect work and then in
> thread 3 i do a cli = new cli(conect args);
> When BckConnect finished is job (in thread 2) i start the BckRead
> (thread 4) to list the root folder of the phone.
> when user select multiple files and say "get to my computer" i start
> again the BckRead (thread 4) with the list of file to transfer and
> made a loop to all files with cli.get_files(fssrce, dest);
> In this loop i use BckRead.reportprogress to interacte with a
> progressbar on GUI(thread2 and then thread 1).
> This stuff work gread under windows, i writed with Zany the author of
> obexftp a little class "cs_stress_test" who run as a console program
> to connect to phone and download a list of file, it work nice under
> linux with a last Mono V1.91.
> But with cs-obexftp during loop the thread is not anymore executed ,
> this occure never at the same time, sometime after the 1th files other
> time after the 14th file
> I see no error in Mono debug output and no error in obexftp debug
> output where i set debug level to 5 (very hight debug )
> The code who use the background worker can be read here :
> http://cs-obexftp.svn.sourceforge.net/viewvc/cs-obexftp/trunk/Cs-ObexFtp/Cs-ObexFtp/Forms/MainForm.cs?view=log
> My point of view is, it could be not a mono problem, but the fact i
> transfert the "cli" object in 3 thread ?
> But why i didn't see it under windows.
> Also i was say " Stability problem under linux MDV 2008 Cooker", so i
> do some test under OpenSuse 11 and problem still here .

More information about the Mono-devel-list mailing list