Re: [Gnoga-list] Crash on ping
On 08/04/2018 04:29 PM, Jeremiah Breeden wrote: > I did not realize that. I've always followed the mantra taught to me about > not > using > them in POs. That's really neat. Should we go ahead > and add a delete loop to it to prevent the potential for someone to start a > connection > between the close and the delete protected calls? Or do you think it will be > alright? It should be true of any compiler, as in general it's impossible to detect potentially blocking operations. This is part of the reason the restriction was a mistake: the language should not have rules it cannot enforce. I haven't looked at the big picture enough to be sure, but I'd think that if the system is in a state where it's closing all connections, it should not allow the creation of a new connection. If it does, then perhaps it should have an atomic Stop operation that closes and deletes all connections, and puts the PO into a state where any further operations raise an exception. It's probably not worth the effort to implement that unless we do encounter problems with it being 2 calls. -- Jeff Carter "My mind is a raging torrent, flooded with rivulets of thought, cascading into a waterfall of creative alternatives." Blazing Saddles 89 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Crash on ping
Le 04/08/2018 à 11:10, Jeffrey R. Carter a écrit : > With GNAT, which we have to use because Gnoga's in Ada 12, you can include > potentially blocking operations in a PO, which is nice, because that > restriction > was a mistake. Calls of potentially blocking operations are generally not detectable at compile time, and are not checked at run-time unless you use a pragma Detect-Blocking. But it's still a bounded error. The restriction is no mistake: without it, it is impossible to make any scheduling or WCET analysis. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Crash on ping
Yep, this is what I meant by the Mutex operation. A mutex is traditionally just a binary semaphore (the implementation you chose). I do the same thing in a lot of my projects (a scope controlled mutex). Thanks for the example! On Sat, Aug 4, 2018 at 8:59 AM, Björn Lundin wrote: > On 2018-08-04 04:03, Jeremiah Breeden wrote: > > Ok, with that in mind, the current set of loops are not being done > atomically (it is not done inside a protected operation). So the next > question is how do we get to where they are done in a more atomic manner. > I started off with a mutex like implementation for the close loop.since the > close procedure could potentially block (and thus could not go in a > protected operation). That wouldn't work for the ping loop without > restructuring the ping procedure itself (and pull out the deletions to be > done afterwards as mentioned in an earlier email/post). > > At work, we sometimes (when tasking) use the pattern below. > > At the end there is a client package with procedures A and B which both > > may affect the same resourse. > > But both start with grabbing a common semaphore which > > will be autmatically released when out of scoope. > > This way we use the same protected object but with no blocking operations > in it. > > But this is perhaps what you meant with mutex operation? > > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Crash on ping
I did not realize that. I've always followed the mantra taught to me about not using them in POs. That's really neat. Should we go ahead and add a delete loop to it to prevent the potential for someone to start a connection between the close and the delete protected calls? Or do you think it will be alright? On Sat, Aug 4, 2018 at 5:10 AM, Jeffrey R. Carter wrote: > On 08/04/2018 04:03 AM, Jeremiah Breeden wrote: > > Ok, with that in mind, the current set of loops are not being done > atomically > > (it is not done inside a protected operation). So the next question is > how do > > we get to where they are done in a more atomic manner. I started off > with a > > mutex like implementation for the close loop.since the close procedure > could > > potentially block (and thus could not go in a protected operation). That > > wouldn't work for the ping loop without restructuring the ping procedure > itself > > (and pull out the deletions to be done afterwards as mentioned in an > earlier > > email/post). > > With GNAT, which we have to use because Gnoga's in Ada 12, you can include > potentially blocking operations in a PO, which is nice, because that > restriction > was a mistake. So I see no problem with putting these loops into protected > operations. Modifying the Ping loop to create a structure of IDs to delete > after > the ping loop should be trivial. > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Crash on ping
On 2018-08-04 04:03, Jeremiah Breeden wrote: > Ok, with that in mind, the current set of loops are not being done > atomically (it is not done inside a protected operation). So the next > question is how do we get to where they are done in a more atomic > manner. I started off with a mutex like implementation for the close > loop.since the close procedure could potentially block (and thus could > not go in a protected operation). That wouldn't work for the ping > loop without restructuring the ping procedure itself (and pull out the > deletions to be done afterwards as mentioned in an earlier email/post). > At work, we sometimes (when tasking) use the pattern below. At the end there is a client package with procedures A and B which both may affect the same resourse. But both start with grabbing a common semaphore which will be autmatically released when out of scoope. This way we use the same protected object but with no blocking operations in it. But this is perhaps what you meant with mutex operation? There are packages Semaphores and Semaphores.Controls to enable this. -- package Semaphores is protected type Semaphore_Type is procedure Release; entry Seize; private In_Use : Boolean := False; end Semaphore_Type; end Semaphores; -- package body Semaphores is protected body Semaphore_Type is procedure Release is begin In_Use := False; end Release; entry Seize when not In_Use is begin In_Use := True; end Seize; end Semaphore_Type; end Semaphores; -- with Ada.Finalization; package Semaphores.Controls is pragma Preelaborate; type Semaphore_Control (Semaphore : access Semaphore_Type) is limited private; private use Ada.Finalization; type Semaphore_Control (Semaphore : access Semaphore_Type) is new Limited_Controlled with null record; procedure Initialize (Control : in out Semaphore_Control); procedure Finalize (Control : in out Semaphore_Control); end Semaphores.Controls; -- package body Semaphores.Controls is procedure Initialize (Control : in out Semaphore_Control) is begin Control.Semaphore.Seize; end Initialize; procedure Finalize (Control : in out Semaphore_Control) is begin Control.Semaphore.Release; end Finalize; end Semaphores.Controls; -- with Semaphores; use Semaphores; with_Semaphores.Controls; use Semaphores.Controls; package body client is Semaphore : aliased Semaphore_Type; -- procedure A is Control : Semaphore_Control (Semaphore'access); pragma Warnings(Off, Control); begin Do_Stuff_1; end A; -- procedure B is Control : Semaphore_Control (Semaphore'access); pragma Warnings(Off, Control); begin Do_Stuff_2; end B; end client; -- -- Björn -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Crash on ping
On 08/04/2018 11:10 AM, Jeffrey R. Carter wrote:
>
> With GNAT, which we have to use because Gnoga's in Ada 12, you can include
> potentially blocking operations in a PO, which is nice, because that
> restriction
> was a mistake. So I see no problem with putting these loops into protected
> operations. Modifying the Ping loop to create a structure of IDs to delete
> after
> the ping loop should be trivial.
I've made the modification for Stop, which compiles fine:
diff --git a/src/gnoga-server-connection.adb b/src/gnoga-server-connection.adb
index da900782..4fe0fcd9 100644
--- a/src/gnoga-server-connection.adb
+++ b/src/gnoga-server-connection.adb
@@ -894,6 +894,9 @@ package body Gnoga.Server.Connection is
procedure Delete_All_Connections;
-- Called by Stop to close down server
+ procedure Close_All;
+ -- Closes all connections
+
function Active_Connections return Ada.Containers.Count_Type;
-- Returns the number of active connections
private
@@ -1101,6 +1104,31 @@ package body Gnoga.Server.Connection is
end loop;
end Delete_All_Connections;
+ procedure Close_All is
+ procedure Close (C : Socket_Maps.Cursor);
+
+ procedure Close (C : Socket_Maps.Cursor) is
+ID : constant Gnoga.Types.Connection_ID := Socket_Maps.Key
(C);
+Socket : constant Socket_Type := Socket_Map.Element
(ID);
+ begin -- Close
+if Socket.Content.Connection_Type = Long_Polling then
+ Socket.Content.Finalized := True;
+else
+ Execute_Script (ID, "ws.close()");
+end if;
+ exception -- Close
+when E : others =>
+ Log ("Error Connection_Manager.Close_All.Close - " & ID'Img);
+ Log (Ada.Exceptions.Exception_Information (E));
+ end Close;
+ begin -- Close_All
+ All_Connections : loop
+exit All_Connections when Socket_Map.Is_Empty;
+
+Close (C => Socket_Map.First);
+ end loop All_Connections;
+ end Close_All;
+
function Active_Connections return Ada.Containers.Count_Type is
begin
return Socket_Map.Length;
@@ -2306,7 +2334,6 @@ package body Gnoga.Server.Connection is
--
procedure Stop is
- ID : Gnoga.Types.Connection_ID;
begin
if not Exit_Application_Requested and
Watchdog /= null and
@@ -2316,12 +2343,7 @@ package body Gnoga.Server.Connection is
Watchdog.Stop;
Watchdog := null;
- Connection_Manager.First (ID);
- while ID /= 0 loop
-Close (ID);
-Connection_Manager.Next (ID);
- end loop;
-
+ Connection_Manager.Close_All;
Connection_Manager.Delete_All_Connections;
Gnoga_HTTP_Server.Stop;
If people use this for a while without problems, we might want to make it
permanent and try something similar for Ping.
--
Jeff Carter
"The time has come to act, and act fast. I'm leaving."
Blazing Saddles
36
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Crash on ping
On 08/04/2018 04:03 AM, Jeremiah Breeden wrote: > Ok, with that in mind, the current set of loops are not being done atomically > (it is not done inside a protected operation). So the next question is how do > we get to where they are done in a more atomic manner. I started off with a > mutex like implementation for the close loop.since the close procedure could > potentially block (and thus could not go in a protected operation). That > wouldn't work for the ping loop without restructuring the ping procedure > itself > (and pull out the deletions to be done afterwards as mentioned in an earlier > email/post). With GNAT, which we have to use because Gnoga's in Ada 12, you can include potentially blocking operations in a PO, which is nice, because that restriction was a mistake. So I see no problem with putting these loops into protected operations. Modifying the Ping loop to create a structure of IDs to delete after the ping loop should be trivial. -- Jeff Carter "The time has come to act, and act fast. I'm leaving." Blazing Saddles 36 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Crash on ping
Ok, with that in mind, the current set of loops are not being done atomically (it is not done inside a protected operation). So the next question is how do we get to where they are done in a more atomic manner. I started off with a mutex like implementation for the close loop.since the close procedure could potentially block (and thus could not go in a protected operation). That wouldn't work for the ping loop without restructuring the ping procedure itself (and pull out the deletions to be done afterwards as mentioned in an earlier email/post). On Fri, Aug 3, 2018 at 5:18 AM, Jeffrey R. Carter wrote: > On 08/03/2018 01:52 AM, Jeremiah Breeden wrote: > > I'm not following on how whether it is atomic helps in this case. Can > you go > > more into detail there? > > > > The issue I ran into (and I think the OP ran into) is that > > > > 1. Task A gets a cursor and saves it, > > 2. does some process (either Ping or Close) > > 3. Iterates the cursor and saves the new one. > > 4. Repeats this in a loop until all cursors are checked > > > > but sometimes Task B deletes the element of that saved cursor while Task > A is at > > step 2. Then when task A hits Step 3, the cursor is invalid and it > throws an > > exception. Prior to the bandaid I suggested, if that happened during the > > "close" loop, it would completely deadlock the close process. The > symptom for > > my application was that when I hit the "terminate program" button, it > wouldn't > > terminate and future attempts to do so would not even try again. The OP > was > > seeing some different results, but I suspect it has to do with the > cursors as well. > > > > My understanding of Atomic in Ada is that it guarantees that > writes/reads are > > not interrupted and that they happen in the order specified. In this > case, the > > problem isn't that the writes or reads are interrupted but that the map > itself > > is being modified while another task holds a cursor to it (thus making > the > > cursor invalid). If this happens during the Ping loop, then it simply > aborts > > the pinging process (maybe/maybe not detrimental). If it interrupts the > Close > > loop, then it (now) restarts the loop and tries again (before it > deadlocked). > > I meant atomic in its generic sense, not as aspect/pragma Atomic. If the > loop is > an atomic operation (provided by the PO), then the other task cannot > interfere > with it. During the Close loop, the program is ending (IIUC), so it doesn't > matter how long it takes. For Ping, how long the loop takes might be an > issue, > but since it's only done once per minute, if there aren't too many > connections, > it might be acceptable. > > -- > Jeff Carter > "I like it when the support group complains that they have > insufficient data on mean time to repair bugs in Ada software." > Robert I. Eachus > 91 > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Gnoga-list mailing list > Gnoga-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gnoga-list > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Crash on ping
On 08/03/2018 01:52 AM, Jeremiah Breeden wrote: > I'm not following on how whether it is atomic helps in this case. Can you go > more into detail there? > > The issue I ran into (and I think the OP ran into) is that > > 1. Task A gets a cursor and saves it, > 2. does some process (either Ping or Close) > 3. Iterates the cursor and saves the new one. > 4. Repeats this in a loop until all cursors are checked > > but sometimes Task B deletes the element of that saved cursor while Task A is > at > step 2. Then when task A hits Step 3, the cursor is invalid and it throws an > exception. Prior to the bandaid I suggested, if that happened during the > "close" loop, it would completely deadlock the close process. The symptom for > my application was that when I hit the "terminate program" button, it wouldn't > terminate and future attempts to do so would not even try again. The OP was > seeing some different results, but I suspect it has to do with the cursors as > well. > > My understanding of Atomic in Ada is that it guarantees that writes/reads are > not interrupted and that they happen in the order specified. In this case, > the > problem isn't that the writes or reads are interrupted but that the map itself > is being modified while another task holds a cursor to it (thus making the > cursor invalid). If this happens during the Ping loop, then it simply aborts > the pinging process (maybe/maybe not detrimental). If it interrupts the Close > loop, then it (now) restarts the loop and tries again (before it deadlocked). I meant atomic in its generic sense, not as aspect/pragma Atomic. If the loop is an atomic operation (provided by the PO), then the other task cannot interfere with it. During the Close loop, the program is ending (IIUC), so it doesn't matter how long it takes. For Ping, how long the loop takes might be an issue, but since it's only done once per minute, if there aren't too many connections, it might be acceptable. -- Jeff Carter "I like it when the support group complains that they have insufficient data on mean time to repair bugs in Ada software." Robert I. Eachus 91 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Crash on ping
I'm not following on how whether it is atomic helps in this case. Can you go more into detail there? The issue I ran into (and I think the OP ran into) is that 1. Task A gets a cursor and saves it, 2. does some process (either Ping or Close) 3. Iterates the cursor and saves the new one. 4. Repeats this in a loop until all cursors are checked but sometimes Task B deletes the element of that saved cursor while Task A is at step 2. Then when task A hits Step 3, the cursor is invalid and it throws an exception. Prior to the bandaid I suggested, if that happened during the "close" loop, it would completely deadlock the close process. The symptom for my application was that when I hit the "terminate program" button, it wouldn't terminate and future attempts to do so would not even try again. The OP was seeing some different results, but I suspect it has to do with the cursors as well. My understanding of Atomic in Ada is that it guarantees that writes/reads are not interrupted and that they happen in the order specified. In this case, the problem isn't that the writes or reads are interrupted but that the map itself is being modified while another task holds a cursor to it (thus making the cursor invalid). If this happens during the Ping loop, then it simply aborts the pinging process (maybe/maybe not detrimental). If it interrupts the Close loop, then it (now) restarts the loop and tries again (before it deadlocked). I think we were trying to figure out if there was a better way to do this. I agree with the Ping suggestion of deferring the deletions until after. My 30 min attempt at making it better was to make the delete procedure an entry, add a mutex like set of entries/procedures to the connection_manager, seize the mutex before calling Connection_Manager.First, and release the Mutex after the loop was done (with the delete procedure now an entry, it would have to wait until after the mutex was released). That would work for the close loop, but the deletions in the Ping function made it too complex to figure out in a short time. Plus I wasn't 100% certain it was a good idea or not to go that route anyways. Sorry for the long post! On Tue, Jul 31, 2018 at 1:24 PM, Jeffrey R. Carter wrote: > On 07/30/2018 06:03 AM, Jeremiah Breeden wrote: > > In Gnoga.Server.Connection.adb search for the two usages of > > Connection_Manager.First. Both will be in a loop. Essentially, one of > the > > problems is that the First operation saves a cursor form the Map, and the > > Connection_Manager.Next tries to iterate on it. However, other tasks can > > sometimes delete the element from the Map between those calls. David > recently > > added a bandaid that I came up with (an Exception Handler around the > "Close" one > > to reset the loop if it happens). The Ping one is already in an > exception > > handler, but the Ping function also calls Delete on the Map, so it can, > in rare > > cases, cause some weird crashes. It's a bit of a hairy implementation > and > > probably needs a revamp. > > Usually these things should be atomic, and I don't see a problem with both > of > these being in Connection_Manager. > > Ping may delete using the ID that is then passed to Next. I'm not sure > what that > will do, but it's usually a bad idea. Better is to collect a set of IDs to > delete and delete them after the iteration. > > I haven't tried any of this yet. > > -- > Jeff Carter > "My brain hurts!" > Monty Python's Flying Circus > 21 > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Gnoga-list mailing list > Gnoga-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gnoga-list > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Crash on ping
On 07/30/2018 06:03 AM, Jeremiah Breeden wrote: > In Gnoga.Server.Connection.adb search for the two usages of > Connection_Manager.First. Both will be in a loop. Essentially, one of the > problems is that the First operation saves a cursor form the Map, and the > Connection_Manager.Next tries to iterate on it. However, other tasks can > sometimes delete the element from the Map between those calls. David recently > added a bandaid that I came up with (an Exception Handler around the "Close" > one > to reset the loop if it happens). The Ping one is already in an exception > handler, but the Ping function also calls Delete on the Map, so it can, in > rare > cases, cause some weird crashes. It's a bit of a hairy implementation and > probably needs a revamp. Usually these things should be atomic, and I don't see a problem with both of these being in Connection_Manager. Ping may delete using the ID that is then passed to Next. I'm not sure what that will do, but it's usually a bad idea. Better is to collect a set of IDs to delete and delete them after the iteration. I haven't tried any of this yet. -- Jeff Carter "My brain hurts!" Monty Python's Flying Circus 21 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Crash on ping
On 07/27/2018 08:08 PM, David Botton wrote: > I am looking (perhaps of Jeff wanted even better, this is his forte :) at > revamping, I think we need to improve the whole section from race conditions > with those maps. Can you point me at the code in question? -- Jeff Carter "It is the German who is so uncourteous to his verbs." A Scandal in Bohemia 122 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Crash on ping
I actually tried to take a quick stab at it at home last week, but the
problem I quickly got caught in was the Ping procedure. It does a lot more
than just ping, it also manages deletions, which made finding a good way to
prevent deletion on an ID while pinging a lot more complex. I initially
started with a mutex style, but quickly found a simple application of it
wasn't going to work (maybe a more complex one though). It seems like
finding a way to separate map management and pinging would help there, or
alternately (as you mentioned) an actual revamp/redo of it (which would
have been cleaner, I was just looking for a solution that I could gen out
and test in the 3 free hours I got after my son went to bed).
On Fri, Jul 27, 2018 at 2:08 PM, David Botton wrote:
> I am looking (perhaps of Jeff wanted even better, this is his forte :) at
> revamping, I think we need to improve the whole section from race
> conditions with those maps.
>
> David Botton
>
> On Fri, Jul 27, 2018 at 1:45 PM Jeremiah Breeden <
> jeremiah.bree...@gmail.com> wrote:
>
>> Is it potentially related to the bug I submitted a fix for a week or two
>> ago? I know the Ping operation in Gnoga.Server.Connection.adb occurred in
>> the same type of for loop that the Close operation did (between a
>> Connection_Manager.First and Connection_Manager.Next call whee the map
>> cursor could be deleted by another process. I didn't submit a fix for the
>> ping side.
>>
>> On Thu, Jul 26, 2018 at 7:37 AM, Gautier de Montmollin <
>> gdem...@hotmail.com> wrote:
>>
>>> Hello,
>>>
>>> First Gnoga server crash, in 1 year of almost uninterrupted service in
>>> the Pasta! game!
>>>
>>> I put hereafter the trace-back in case someone wants (and knows how) to
>>> do something good about it...
>>>
>>> Cheers
>>>
>>> Gautier
>>>
>>> _
>>>
>>> 2018-07-22 06:26:30.09 : Ping on websocket - 27
>>> 2018-07-22 06:27:30.09 : Ping on websocket - 27
>>> 2018-07-22 06:27:30.10 : Ping 27 error.
>>> 2018-07-22 06:27:30.10 : raised GNAT.SOCKETS.SOCKET_ERROR : [10053]
>>> Software caused connection abort
>>>
>>> Here is the call stack trace-back:
>>>
>>> gnoga_dev_1.3-2017_04_11/deps/simple_components/atomic-
>>> access/gcc-long-offsets/gnat-sockets-server.adb:948
>>> [ Send_Socket (Client.Socket, Data, Last); ]
>>> gnoga_dev_1.3-2017_04_11/deps/simple_components/gnat-
>>> sockets-connection_state_machine-http_server.adb:3574
>>> [ Push (Client, Data (Pointer..Data'Last), Next); ]
>>> gnoga_dev_1.3-2017_04_11/deps/simple_components/gnat-
>>> sockets-connection_state_machine-http_server.adb:3886
>>> [ WebSocket_Blocking_Send (Client, Header, True, False); ]
>>> gnoga_dev_1.3-2017_04_11/src/gnoga-server-connection.adb:1197 [
>>> Socket.WebSocket_Send ("0"); ]
>>> gnoga_dev_1.3-2017_04_11/src/gnoga-server-connection.adb:1240 [ Ping
>>> (ID); ]
>>>
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Gnoga-list mailing list
>>> Gnoga-list@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>>>
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot__
>> _
>> Gnoga-list mailing list
>> Gnoga-list@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Gnoga-list mailing list
> Gnoga-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Crash on ping
I am looking (perhaps of Jeff wanted even better, this is his forte :) at
revamping, I think we need to improve the whole section from race
conditions with those maps.
David Botton
On Fri, Jul 27, 2018 at 1:45 PM Jeremiah Breeden
wrote:
> Is it potentially related to the bug I submitted a fix for a week or two
> ago? I know the Ping operation in Gnoga.Server.Connection.adb occurred in
> the same type of for loop that the Close operation did (between a
> Connection_Manager.First and Connection_Manager.Next call whee the map
> cursor could be deleted by another process. I didn't submit a fix for the
> ping side.
>
> On Thu, Jul 26, 2018 at 7:37 AM, Gautier de Montmollin <
> gdem...@hotmail.com> wrote:
>
>> Hello,
>>
>> First Gnoga server crash, in 1 year of almost uninterrupted service in
>> the Pasta! game!
>>
>> I put hereafter the trace-back in case someone wants (and knows how) to
>> do something good about it...
>>
>> Cheers
>>
>> Gautier
>>
>> _
>>
>> 2018-07-22 06:26:30.09 : Ping on websocket - 27
>> 2018-07-22 06:27:30.09 : Ping on websocket - 27
>> 2018-07-22 06:27:30.10 : Ping 27 error.
>> 2018-07-22 06:27:30.10 : raised GNAT.SOCKETS.SOCKET_ERROR : [10053]
>> Software caused connection abort
>>
>> Here is the call stack trace-back:
>>
>> gnoga_dev_1.3-2017_04_11/deps/simple_components/atomic-access/gcc-long-offsets/gnat-sockets-server.adb:948
>>
>> [ Send_Socket (Client.Socket, Data, Last); ]
>> gnoga_dev_1.3-2017_04_11/deps/simple_components/gnat-sockets-connection_state_machine-http_server.adb:3574
>>
>> [ Push (Client, Data (Pointer..Data'Last), Next); ]
>> gnoga_dev_1.3-2017_04_11/deps/simple_components/gnat-sockets-connection_state_machine-http_server.adb:3886
>>
>> [ WebSocket_Blocking_Send (Client, Header, True, False); ]
>> gnoga_dev_1.3-2017_04_11/src/gnoga-server-connection.adb:1197 [
>> Socket.WebSocket_Send ("0"); ]
>> gnoga_dev_1.3-2017_04_11/src/gnoga-server-connection.adb:1240 [ Ping
>> (ID); ]
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Gnoga-list mailing list
>> Gnoga-list@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Gnoga-list mailing list
> Gnoga-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Crash on ping
Is it potentially related to the bug I submitted a fix for a week or two
ago? I know the Ping operation in Gnoga.Server.Connection.adb occurred in
the same type of for loop that the Close operation did (between a
Connection_Manager.First and Connection_Manager.Next call whee the map
cursor could be deleted by another process. I didn't submit a fix for the
ping side.
On Thu, Jul 26, 2018 at 7:37 AM, Gautier de Montmollin
wrote:
> Hello,
>
> First Gnoga server crash, in 1 year of almost uninterrupted service in
> the Pasta! game!
>
> I put hereafter the trace-back in case someone wants (and knows how) to
> do something good about it...
>
> Cheers
>
> Gautier
>
> _
>
> 2018-07-22 06:26:30.09 : Ping on websocket - 27
> 2018-07-22 06:27:30.09 : Ping on websocket - 27
> 2018-07-22 06:27:30.10 : Ping 27 error.
> 2018-07-22 06:27:30.10 : raised GNAT.SOCKETS.SOCKET_ERROR : [10053]
> Software caused connection abort
>
> Here is the call stack trace-back:
>
> gnoga_dev_1.3-2017_04_11/deps/simple_components/atomic-
> access/gcc-long-offsets/gnat-sockets-server.adb:948
> [ Send_Socket (Client.Socket, Data, Last); ]
> gnoga_dev_1.3-2017_04_11/deps/simple_components/gnat-
> sockets-connection_state_machine-http_server.adb:3574
> [ Push (Client, Data (Pointer..Data'Last), Next); ]
> gnoga_dev_1.3-2017_04_11/deps/simple_components/gnat-
> sockets-connection_state_machine-http_server.adb:3886
> [ WebSocket_Blocking_Send (Client, Header, True, False); ]
> gnoga_dev_1.3-2017_04_11/src/gnoga-server-connection.adb:1197 [
> Socket.WebSocket_Send ("0"); ]
> gnoga_dev_1.3-2017_04_11/src/gnoga-server-connection.adb:1240 [ Ping
> (ID); ]
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Gnoga-list mailing list
> Gnoga-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
[Gnoga-list] Crash on ping
Hello,
First Gnoga server crash, in 1 year of almost uninterrupted service in
the Pasta! game!
I put hereafter the trace-back in case someone wants (and knows how) to
do something good about it...
Cheers
Gautier
_
2018-07-22 06:26:30.09 : Ping on websocket - 27
2018-07-22 06:27:30.09 : Ping on websocket - 27
2018-07-22 06:27:30.10 : Ping 27 error.
2018-07-22 06:27:30.10 : raised GNAT.SOCKETS.SOCKET_ERROR : [10053]
Software caused connection abort
Here is the call stack trace-back:
gnoga_dev_1.3-2017_04_11/deps/simple_components/atomic-access/gcc-long-offsets/gnat-sockets-server.adb:948
[ Send_Socket (Client.Socket, Data, Last); ]
gnoga_dev_1.3-2017_04_11/deps/simple_components/gnat-sockets-connection_state_machine-http_server.adb:3574
[ Push (Client, Data (Pointer..Data'Last), Next); ]
gnoga_dev_1.3-2017_04_11/deps/simple_components/gnat-sockets-connection_state_machine-http_server.adb:3886
[ WebSocket_Blocking_Send (Client, Header, True, False); ]
gnoga_dev_1.3-2017_04_11/src/gnoga-server-connection.adb:1197 [
Socket.WebSocket_Send ("0"); ]
gnoga_dev_1.3-2017_04_11/src/gnoga-server-connection.adb:1240 [ Ping
(ID); ]
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
