Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Library : Other (not classified elsewhere) » Segfaults with One container?
Segfaults with One container? [message #23172] Tue, 22 September 2009 13:21 Go to next message
phirox is currently offline  phirox
Messages: 49
Registered: December 2007
Member
I've had a really weird bug in my program, and have been able to downsize it to the following testcase. But I still cannot track what is going on(using v1517):

#include <Core/Core.h>
#include <Web/Web.h>

using namespace Upp;

CONSOLE_APP_MAIN
{
	Cout() << "main1\n";
	Socket s;
	Cout() << "main2\n";
	s.NoBlock();
	Cout() << "main3\n";
}


Results in:

Quote:


main1
main2
Assertion failed in /home/phirox/upp/uppsrc/Core/Other.h, line 17
ptr



My idea is that accessing any variable in the One<Data> object part of the new socket is making it crash. I've tried using several compilers and even other machines, but they all reproduce this result.
Re: Segfaults with One container? [message #23173 is a reply to message #23172] Tue, 22 September 2009 17:52 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
phirox wrote on Tue, 22 September 2009 07:21

I've had a really weird bug in my program, and have been able to downsize it to the following testcase. But I still cannot track what is going on(using v1517):

#include <Core/Core.h>
#include <Web/Web.h>

using namespace Upp;

CONSOLE_APP_MAIN
{
	Cout() << "main1\n";
	Socket s;
	Cout() << "main2\n";
	s.NoBlock();
	Cout() << "main3\n";
}


Results in:

Quote:


main1
main2
Assertion failed in /home/phirox/upp/uppsrc/Core/Other.h, line 17
ptr



My idea is that accessing any variable in the One<Data> object part of the new socket is making it crash. I've tried using several compilers and even other machines, but they all reproduce this result.



Socket must be open prior to calling NoBlock.

Mirek
Re: Segfaults with One container? [message #23177 is a reply to message #23172] Wed, 23 September 2009 09:22 Go to previous messageGo to next message
phirox is currently offline  phirox
Messages: 49
Registered: December 2007
Member
Thank you for your fast response, and as always it was right on. I think I have stared to long at the problem to notice it myself Smile

For future references the solution for me was to add the following code:

	s.Init();
	One<Socket::Data> data = new Socket::Data;
	s.Attach(data);


The reason for all of this; under *nix when you fork() or reload your own or other program with exec() all sockets are inherited. So for example by just adding
data->socket = 3;
in the above example you can continue working on it without interruption. Maybe an idea to add this feature as a function OldSocket/OpenedSocket besides the existing ClientSocket and ServerSocket?

[Updated on: Wed, 23 September 2009 13:45]

Report message to a moderator

Re: Segfaults with One container? [message #23180 is a reply to message #23177] Thu, 24 September 2009 09:43 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
phirox wrote on Wed, 23 September 2009 03:22

Thank you for your fast response, and as always it was right on. I think I have stared to long at the problem to notice it myself Smile

For future references the solution for me was to add the following code:

	s.Init();
	One<Socket::Data> data = new Socket::Data;
	s.Attach(data);


The reason for all of this; under *nix when you fork() or reload your own or other program with exec() all sockets are inherited. So for example by just adding
data->socket = 3;
in the above example you can continue working on it without interruption. Maybe an idea to add this feature as a function OldSocket/OpenedSocket besides the existing ClientSocket and ServerSocket?


I am not quite happy about this; I think Socket::Data should in fact be private. I guess Socket::Attach(SOCKET) would solve the problem, right?
Re: Segfaults with One container? [message #23183 is a reply to message #23180] Thu, 24 September 2009 10:22 Go to previous messageGo to next message
phirox is currently offline  phirox
Messages: 49
Registered: December 2007
Member
luzr wrote on Thu, 24 September 2009 09:43

I am not quite happy about this; I think Socket::Data should in fact be private. I guess Socket::Attach(SOCKET) would solve the problem, right?


Such a function would be great, but would need one addition. Socket settings such as linger/blocking/delay will not be saved in the class specific variables, even though they will remain effective on the socket itself. I can find only one that is really used; to determine if to peek or directly read. So the function should at least be Socket::Attach(SOCKET, is_blocking)
Re: Segfaults with One container? [message #23188 is a reply to message #23183] Thu, 24 September 2009 11:06 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
phirox wrote on Thu, 24 September 2009 04:22

luzr wrote on Thu, 24 September 2009 09:43

I am not quite happy about this; I think Socket::Data should in fact be private. I guess Socket::Attach(SOCKET) would solve the problem, right?


Such a function would be great, but would need one addition. Socket settings such as linger/blocking/delay will not be saved in the class specific variables, even though they will remain effective on the socket itself. I can find only one that is really used; to determine if to peek or directly read. So the function should at least be Socket::Attach(SOCKET, is_blocking)


BTW, I must have missed something, but why you dont just keep using the same Socket after fork?

Mirek
Re: Segfaults with One container? [message #23192 is a reply to message #23188] Thu, 24 September 2009 12:25 Go to previous messageGo to next message
phirox is currently offline  phirox
Messages: 49
Registered: December 2007
Member
luzr wrote on Thu, 24 September 2009 11:06


BTW, I must have missed something, but why you dont just keep using the same Socket after fork?

Mirek


Because fork was just an example of one of the methods. I use exec(), which starts a whole new process. I catch the HUP signal which reloads the binary, basically giving the ability to update my program without losing any connections. It does this by saving every class variable that is necessary in a sessions file(xml) and then loading it back in the new binary. Which then resumes the socket connections.
Re: Segfaults with One container? [message #23236 is a reply to message #23192] Fri, 02 October 2009 10:01 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
phirox wrote on Thu, 24 September 2009 06:25

luzr wrote on Thu, 24 September 2009 11:06


BTW, I must have missed something, but why you dont just keep using the same Socket after fork?

Mirek


Because fork was just an example of one of the methods. I use exec(), which starts a whole new process. I catch the HUP signal which reloads the binary, basically giving the ability to update my program without losing any connections. It does this by saving every class variable that is necessary in a sessions file(xml) and then loading it back in the new binary. Which then resumes the socket connections.


Well, Linger and NoDelay are not stored in member variables, so that leaves us with blocking. I was thinking about reading this value from system (on Attach), but it seems like this is not possible in Win32.

Therefore, for now:

void AttachSocket(Socket& socket, SOCKET s, bool blocking)


(Note this is a global function, because Socket is supposed to support SSL sockets too...).

Mirek

Previous Topic: Dockmenu Draw
Next Topic: How to set a global (system) keyboard hook?
Goto Forum:
  


Current Time: Fri Mar 29 07:48:23 CET 2024

Total time taken to generate the page: 0.02014 seconds