On 05/30/2011 03:31 PM, Benoît Minisini wrote: >> Any reason a compiled app would behave differently than an app run in >> the IDE? My app stalls half-way through receiving network packets from >> the server when compiled, but when both are running in the IDE it works >> fine. Didn't have this problem earlier tonight. This is new to me. I'm >> using build 3866. > > Mmm. Very hard to guess as soon as you do network programming. > > When your program is stalled, do that in a terminal: > > $ gdb /usr/bin/gbx3<pid of your application> > ... > (gdb) bt > ... > > And send me the result of the 'bt' command, which should tell where the > program is stalled. > > Note: replace /usr/bin/gbx3 by where the gambas interpreter is actually > installed.
When I said "stalled" I meant it continued execution but without processing the expected events (it didn't freeze or raise an error). I'm sorry for not being more specific. I've also discovered it has nothing to do with whether or not the program has been compiled. That was a red herring. This is what is happening: The client sends its username and password to the server. The server tells the client that it has authenticated, then begins to send it multiple transactions (packets) with the information that it needs to start the game. All the transactions use the same procedures (client and server share transaction processing code), so the theory is that if one works they should all work. It has worked in the past, so I think a change in programming logic (multiple medium-sized packets in sequence) may have exposed a bug. The weird thing that started happening is that a series of similar transactions being sent by the server began to be received irregularly by the client. Frequently the number of successful transactions changes between sequential program runs. Usually I expect something to fail consistently, not work sometimes then fail other times, so it's very confusing. Also it seems like the smaller the packet size the less frequently it fails. For example, if the server sends a series of nine packets to the client, each around 25K, the client will receive less than nine 100% of the time. If the server sends nine 15K packets the client may fail to receive them all 75% of the time. If the packets are under 10K then it may fail 25% of the time. Also sometimes the client receives packets with packets missing in the middle. For example, the client may receive packets 0 - 8, miss packets 9 - 11, and finally receive packet 12. The server is actually sending all the UDP data properly. I've step-traced the client and the UDP_Read event is simply not triggered for the missing packets. It's like they're lost in the wire...like they disappeared. I thought it might be a hardware problem, so I tried it with different combinations of bare metal and VMs. I even upgraded my kernel and used more recent NIC firmware. No effect at all, so I don't think it's hardware or my code. Anyone have any insight? -- Kevin Fishburne Eight Virtues www: http://sales.eightvirtues.com e-mail: [email protected] phone: (770) 853-6271 ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Gambas-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gambas-user
