udp socket bug on daily build 2883 and later

Solar2D Network
#1

For other developers that may be using udp connections (I don’t know if this applies to tcp as well).

I noticed that using daily build 2883 or later (which was when Corona updated LuaSocket to 3.0-rc1) I started to see the following issue (I am using MAC):

When I start the project for 1st time I can listen broadcast packets (sent by another non-corona device) normally, but if I restart the simulator it stops seeing the packets.  

The only way I can see the packets back is restarting my broadcast device and then Corona. 

I also noticed that on that daily buiild and later I see the following when running udp:getsockname()

udp:setsockname("\*", 3421)  print("getsockname=", udp:getsockname()) -- outputs  getsockname= :: 3421

while when using a daily build older than 2883 (where the udp works fine when restarting), I get:

-- outputs  getsockname=0.0.0.0 3421

don’t know if that is an indication of the problem.

Any case, if you face that type of behavior, try downgrading your Corona.

And for Corona, the daily docs are still saying that Corona is using LuaSocket 2.02.

PS:  I tested my udp code using pure lua and luasocket 3.0rc1-2  (downloaded via luarocks) and I don’t see that bug happening.

#2

Can you file a bug report please?

Thanks

Rob

#3

The “::” looks like a null IPv6 address:

print("getsockname=", udp:getsockname()) -- outputs  getsockname= :: 3421

while:

-- outputs  getsockname=0.0.0.0    3421

looks like a null IPv4 address.

If you can supply a test case for the other issue (restarting the simulation) I’ll be able to take a look at what might be going on.   Does it make any difference if you close the socket before restarting the app?  I understand this isn’t a solution, just trying to narrow things down.

#4

Have this issue been resolved? seeing same problem on my project.

#5

Did anyone file a bug report?

Rob

#6

I did not. If we’re touching this subject, what’s the point of filing a bug in your system? I’ve filed dozens of bugs and there is no where to follow up or know when you intend to resolve them. I never received an update on one of my bugs being solved. Most updates came through following subjects in the forum.

#7

We do respond to our bug reports and we are constantly closing them with fixes. We know there is no visibility into the tracker. You get emails from the bug tracker and you can always reply to those emails to update the tickets. I’ll look into your submissions and email you about them.

Rob

#8

I am with @rune7.  I also don’t have any motivation anymore to submit bugs. I have several of them submitted that I didn’t get any reply and they are years old. There was a case that I even received an email back saying that the bug was fixed, then I tested and it was not. I replied the email saying that it was not fixed and I was simply ignored.  The bug still happens today.

What I do today is have a local txt file where I list down the bugs that I found and the workaround and that is it.  Only when I face specific bugs that took me hours to figure out that I post here on the forum to make other developers aware (so they can avoid spending hours on it).

Unfortunately, as a client point of view, I find a too bureaucracy position from Corona to ask us to fill out the bug submission form (which is not very friendly also) when we already described the bug on the forum. I think it is not our job to do that. If we place a bug info in the forum and any person from the Corona team see it, it should be that Corona employee duty to fill out a bug form and place a link to the forum post just for tracking purposes.  IMHO, it is a very lazy position from Corona to simply ignore bugs that they are already got to know about on the forum and just don’t take any action just because none of their customers wanted to fill out the long bug submission form.

Of course, what I stated above does not apply to all Corona employees. I have several cases where Joshua, Brian & others saw a bug on the forum and quickly fixed it without requiring us to fill out bug forms before they took any action. That is what a customer-centric startup should be about.

#9

We can’t fill out your bug report for you for two main reasons.

  1. We don’t have a test case that reproduces the problem. If we did, there wouldn’t be a bug. It can take us hours upon hours to try and re-create a problem, with a high chance that we can’t reproduce it when we are having to guess at what you’re doing. You see the problem. You’ve narrowed down the cause. It’s simply better for you to produce the test case. It’s not laziness, it’s practicality.  If it wasn’t for the need of a demonstration project, I’m sure we would fill out many more bug reports for you. And FYI, if I can reproduce it, I will try and fill out the bug for the you, but that leads to the second problem.

  2. Our bug tracker works through email. If an engineer working on your case needs more information, it’s very inefficient for them to leave the bug tracker, go try and find a forum thread and ask there when they can simply hit reply, send you an email message, you response with the info they need and they go back to working on your bug. If I file the bug report for you, guess who gets the emails asking for more info? Me. And I generally won’t have it since I’m not working with your use case.

Sure sometimes we see a bug on the forums and if it’s critical, we are on it with out a bug case. But those are all likely emergency cases (can’t submit to the store, simulator crashes when starting up, etc.) or it’s very obvious what the problem is. We will continue to fix those when it makes sense. But 99% of the time we need your sample app to see the bug and that is why you need to file the bug.

Finally forums don’t allow assigning tasks to people. Bugs needs to be in the bug tracking system and at the end of the day, the only practical person to file the bug report is you.

Rob

#10

Yes, it is practical for you but not for us. 

We usually found bugs in a middle of our projects, so it is not simple or direct to simply create a test case.

A very simple example is this thread.  I stated very clear the problem “When I start the project for 1st time I can listen broadcast packets (sent by another non-corona device) normally, but if I restart the simulator it stops seeing the packets.”. 

That one line description is more than sufficient for anyone with minimum development skills to recreate the scenario.  I got to know Corona engineers and I know they are top class. I have not doubt that anyone there can read that sentence and recreate that situation without any question.

Now for me, I cannot simply get my whole app+server project to send to you. Also, I don’t want to stop my work for ~1 hour to create the test project, fill out the form, submit and pray for one day Corona see it and fix it. So, for me it is not worthy at all.  If all bugs report were fixed in a short time, it would be different. I would think: “Ok, I am okay spending 1 hour  here to have the bug fix in 2 weeks”. But usually that is not the case. You spend your time and it takes months or even years.

About your 2nd point, I don’t think a software limitation should be a reason to simply make the life of clients worse. I am pretty sure you can add the forum post URL attached to the bug description. So whoever is taking care of the bug can just click on the forum link and paste there any request or update about it.

And about “Finally forums don’t allow assigning tasks to people.”.  Of course I am not saying that you shouldn’t use a bug tracker, you should use.  I am just saying that ignore bugs reports that are posted in the forum just because no one created a bug report is not something that I think it should be done.  That position is like a company employee that sees a problem with the company product and simply don’t report to its superior because it is not their primary job.

To finalize, that is just my opinion. I don’t want to enter here in a discussion about that because I am sure that you will get back with other problems. But for me, it alls sum up to the mantra “A man who wants something will find a way; a man who doesn’t will find an excuse.”.

 I just wanted to share it because I believe that other developers see that as the same as I and are simply not filling bug reports anymore because they don’t see value on it. In the end, it is Corona that loses the opportunity to get know the problem on its product and improved it.

#11

Hi Renato,

You need to make some checks now before using the socket lib. Luckily It has been already worked on by Corona team for the old Autolan project so I took this snippet from there. Simply replace your socketlib calls with the respective socketUDP or socketTCP methods below. I think this should have been posted as a thread somewhere along with that build that changed the socket library version.

-- Check if this is socket 2 or later local isSocket2 = (string.match( socketlib.\_VERSION, "LuaSocket 2" ) ~= nil ) local forceIPV4 = true local socketUDP = (isSocket2) and socketlib.udp or(socketlib.udp6 or socketlib.udp4 or socketlib.udp) local socketTCP = (isSocket2) and socketlib.tcp or(socketlib.tcp6 or socketlib.tcp4 or socketlib.tcp) if( forceIPV4 and isSocket2 == false ) then socketUDP = socketlib.udp4 or socketlib.udp socketTCP = socketlib.tcp4 or socketlib.tcp end --
#12

A very simple example is this thread.  I stated very clear the problem “When I start the project for 1st time I can listen broadcast packets (sent by another non-corona device) normally, but if I restart the simulator it stops seeing the packets.”. 

 

That one line description is more than sufficient for anyone with minimum development skills to recreate the scenario.  I got to know Corona engineers and I know they are top class. I have not doubt that anyone there can read that sentence and recreate that situation without any question.

 

The reason we ask for bug reports is that a lot of the time when we get a problem report the issue just doesn’t appear when someone else tries to reproduce it from the description.  This is a case in point.  You can run the attached app I made to reproduce the problem and see that it works fine (as I expected it would given the testing we did before shipping the new version).

 

Note that I am not saying there isn’t a problem, just that the person experiencing it is the one in the position to reproduce it.  And, a surprising amount of the time, when someone goes to create a simple, reproducible case they realize where the error is in their own code (not that I’m saying that’s the case here).

 

All of this goes double for network code which is hard to do and prone to seeming to work despite minor errors which become issues when software versions change.

 

 

 

#13

Can you file a bug report please?

Thanks

Rob

#14

The “::” looks like a null IPv6 address:

print("getsockname=", udp:getsockname()) -- outputs  getsockname= :: 3421

while:

-- outputs  getsockname=0.0.0.0    3421

looks like a null IPv4 address.

If you can supply a test case for the other issue (restarting the simulation) I’ll be able to take a look at what might be going on.   Does it make any difference if you close the socket before restarting the app?  I understand this isn’t a solution, just trying to narrow things down.

#15

Have this issue been resolved? seeing same problem on my project.

#16

Did anyone file a bug report?

Rob

#17

I did not. If we’re touching this subject, what’s the point of filing a bug in your system? I’ve filed dozens of bugs and there is no where to follow up or know when you intend to resolve them. I never received an update on one of my bugs being solved. Most updates came through following subjects in the forum.

#18

We do respond to our bug reports and we are constantly closing them with fixes. We know there is no visibility into the tracker. You get emails from the bug tracker and you can always reply to those emails to update the tickets. I’ll look into your submissions and email you about them.

Rob

#19

I am with @rune7.  I also don’t have any motivation anymore to submit bugs. I have several of them submitted that I didn’t get any reply and they are years old. There was a case that I even received an email back saying that the bug was fixed, then I tested and it was not. I replied the email saying that it was not fixed and I was simply ignored.  The bug still happens today.

What I do today is have a local txt file where I list down the bugs that I found and the workaround and that is it.  Only when I face specific bugs that took me hours to figure out that I post here on the forum to make other developers aware (so they can avoid spending hours on it).

Unfortunately, as a client point of view, I find a too bureaucracy position from Corona to ask us to fill out the bug submission form (which is not very friendly also) when we already described the bug on the forum. I think it is not our job to do that. If we place a bug info in the forum and any person from the Corona team see it, it should be that Corona employee duty to fill out a bug form and place a link to the forum post just for tracking purposes.  IMHO, it is a very lazy position from Corona to simply ignore bugs that they are already got to know about on the forum and just don’t take any action just because none of their customers wanted to fill out the long bug submission form.

Of course, what I stated above does not apply to all Corona employees. I have several cases where Joshua, Brian & others saw a bug on the forum and quickly fixed it without requiring us to fill out bug forms before they took any action. That is what a customer-centric startup should be about.

#20

We can’t fill out your bug report for you for two main reasons.

  1. We don’t have a test case that reproduces the problem. If we did, there wouldn’t be a bug. It can take us hours upon hours to try and re-create a problem, with a high chance that we can’t reproduce it when we are having to guess at what you’re doing. You see the problem. You’ve narrowed down the cause. It’s simply better for you to produce the test case. It’s not laziness, it’s practicality.  If it wasn’t for the need of a demonstration project, I’m sure we would fill out many more bug reports for you. And FYI, if I can reproduce it, I will try and fill out the bug for the you, but that leads to the second problem.

  2. Our bug tracker works through email. If an engineer working on your case needs more information, it’s very inefficient for them to leave the bug tracker, go try and find a forum thread and ask there when they can simply hit reply, send you an email message, you response with the info they need and they go back to working on your bug. If I file the bug report for you, guess who gets the emails asking for more info? Me. And I generally won’t have it since I’m not working with your use case.

Sure sometimes we see a bug on the forums and if it’s critical, we are on it with out a bug case. But those are all likely emergency cases (can’t submit to the store, simulator crashes when starting up, etc.) or it’s very obvious what the problem is. We will continue to fix those when it makes sense. But 99% of the time we need your sample app to see the bug and that is why you need to file the bug.

Finally forums don’t allow assigning tasks to people. Bugs needs to be in the bug tracking system and at the end of the day, the only practical person to file the bug report is you.

Rob