[Gambas-user] PING > Benoît (ServerSocket)

[Benoît Minisini]

> On Thu, 2009-11-05 at 10:53 +0100, Benoît Minisini wrote:
> > > Benoît,
> > >
> > > I'd like to ask you take a look at something, please. I've been tearing
> > > my hair out over this problem for weeks, but now that I've finally
> > > nailed it, I can't reproduce it. I encountered this problem a few weeks
> > > back in the ServerSocket component; my code had been working great for
> > > weeks then suddenly it stopped dead, for no reason that I could explain
> > > except a reboot (one day it worked, the next it didn't). I even went to
> > > the trouble of a format and clean install, and still had the problem
> > > (Ubuntu 9.04 x86 and 9.10 x64).
> > >
> > > To cut a short story long, to find out what the problem was, I created
> > > a project from the ServerSocket example in 2.17 (I was using 2.16 last
> > > time this happened, and it was the same with the much earlier version
> > > supplied with Ubuntu 9.04).
> > >
> > > I then stripped the example down to get rid of all the buttons and
> > > other adornments on the screen: The code attached in A1.tar.gz worked;
> > > it is the stripped-down ServerSocket example I was using as a benchmark
> > > against my own code.
> > >
> > > Next, I stripped absolutely everything out of my no longer working code
> > > and manually edited it, one change at a time, line for line, to make it
> > > match precisely what is in A1.tar.gz, which works. When I say precisely
> > > I mean I even changed the variable names to match, and every single
> > > newline was replicated as well. I ran my code at each change, and each
> > > time either:
> > >
> > > 1) PUBLIC SUB Socket_Read() failed to fire
> > >
> > > Or
> > >
> > > 2) WRITE #Client, "200 Get lost! Leave me alone!\r\n", Len("200 Get
> > > lost! Leave me alone!\r\n") in procedure PUBLIC SUB Socket_Ready()
> > > failed to reach the client.
> > >
> > > It has to be one of those two, I can't say which one, but I can say
> > > that PUBLIC SUB Socket_Ready was firing <-- It was firing. Anyway I got
> > > down to the very last change I could possibly make so that my own code
> > > matched the working, modified example ServerSocket code exactly. That
> > > change was this:
> > >
> > > The working code
> > > ================
> > >
> > > PUBLIC SUB Form_Open()
> > >
> > >   Server.Type = Net.Internet
> > >   Server.Port = 5001
> > >   Server.Listen(1)
> > >
> > > END
> > >
> > > The not working code
> > > ====================
> > >
> > > PUBLIC SUB Form_Open()
> > >
> > >   Server.Port = 5001
> > >   Server.Type = Net.Internet
> > >   Server.Listen(1)
> > >
> > > END
> > >
> > > As soon as I ran my code after swapping the Server.Port and Server.Type
> > > lines, I swear, it worked. So I reversed the change and it still
> > > worked :(
> > >
> > > So I created a new project, added a ServerSocket control named Server,
> > > pasted in the not working code prior to the line swap, and it worked as
> > > well :(
> > >
> > > Ok, either I am going nuts or my Gambas has made a liar out of me.
> > > Perhaps I am crazy and ought to be locked up in a rubber room with a
> > > straight-jacket on?
> > >
> > > Is there any possible way that setting Server.Port before Server.Type
> > > could cause ServerSocket to behave oddly? Could an Ubuntu update
> > > overwrite something that ServerSocket uses and thereby cause
> > > ServerSocket to stop working suddenly --> if and only if Server.Port is
> > > set before Server.Type? Am I really insane? Inquiring minds that don't
> > > want to be labelled "MAD!!!" want to know.
> > >
> > > Truly, I cannot now reproduce this problem after that line swap. The
> > > code continues to work, no matter what inhumane atrocities I commit
> > > upon it.
> > >
> > > I am so frustrated by this problem that if you tell me that I am indeed
> > > insane I will probably believe you.
> >
> > I'm sorry, but setting the Port and Type property does nothing except
> > storing the integer values in memory. These properties are used when you
> > call Listen().
> >
> > I'm not completely sure this is a Gambas problem, as in your previous
> > mail you said that, when your program suddenly stopped working, the
> > ServerSocket example stopped working too. And that rebooting changed
> > nothing: the only way for Gambas to do that after a reboot is killing
> > your network card!
> >
> > If only you have noticed the full "broken pipe" error message... :-s. If
> > you have the problem again, please note it carefully!
> 
> Ok, so I'm crazy.
> 

No. I don't think so. :-)

But if rebooting your Linux server does not make the application work again, I 
can't really suspect Gambas, as it does not save anything on the hard disk, 
especially the network component.

Did you test the connection with telnet, or any other non-Gambas program? Did 
you test another socket server application not made in Gambas?

The only possibility I see would be a memory corruption in the network 
component - it is possible, I didn't write it :-). By reading the source code 
of the Listen() method, I didn't see anything that could lead to that. But I 
will check again.

A way to see these kinds of error is running Gambas inside valgrind:

$ cd /path/to/my/application/project
$ valgrind --tool=memcheck --num-callers=40 --track-origins=yes gbx2
...

And tell me all the messages reported by valgrind during the life of the 
application.


> The broken pipe error is irrelevant because I am using a different
> machine and still have the same issue.
> 

I thought you were talking about an error message from your gambas 
application.

> > the ServerSocket example stopped working too
> 
> Yes, it did.
> 
> I'll keep my eye on the problem. I want to be able to say, "I TOLD YOU
> SO!!!"
> 
> Mind you, it doesn't exactly instil confidence in me to bother getting
> the application finished.
> 

If the information you gave are all exact (rebooting changed nothing, suddenly 
everything works again), the problem should come from something outside of the 
operating system.

Regards,

-- 
Benoît Minisini