[
https://issues.apache.org/jira/browse/THRIFT-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912720#action_12912720
]
Christian Lavoie commented on THRIFT-900:
-----------------------------------------
Still broken:
{noformat}
$ ./myServer
Starting the server...
myServer(33952) malloc: *** error for object 0x7fff5fbff370: pointer being
freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap
{noformat}
The following hunk is still bogus, but for more subtle reasons ;)
{noformat}
@@ -267,6 +300,16 @@
// connects or push the exception up.
for (res = res0; res; res = res->ai_next) {
try {
+ //hijack res struct for UNIX Socket
+ if (! path_.empty()) {
+ res->ai_family = PF_UNIX;
+ res->ai_socktype = SOCK_STREAM;
+ res->ai_protocol = IPPROTO_IP;
+
+ address.sun_family = AF_UNIX;
+ res->ai_addrlen = sizeof(address.sun_family) +
sprintf(address.sun_path, path_.c_str());
+ res->ai_addr = (struct sockaddr *) &address;
+ }
openConnection(res);
break;
} catch (TTransportException& ttx) {
{noformat}
Now when the following code gets run:
{noformat}
277
278 // free addrinfo
279 freeaddrinfo(res0);
280
{noformat}
freeaddrinfo tries to free res->ai_addr recursively (I suspect) and correctly
says it's a pointer that wasn't allocated by the right routine (I suspect most
implementations just call malloc, but I don't expect that's required by w\e the
relevant spec is). In effect you're asking it to free a random subset of the
memory allocated for your TServerSocket (whatever that address membervar was
assigned).
I can think of a few ways to fix the problem:
1) assign NULL to that pointer just before freeaddrinfo when necessary. Ugly,
and makes the code paths harder and harder to figure out.
2) find the correct API sequence for unix sockets, the *addrinfo calls clearly
assume they own the pointers and you're probably not expected to be mucking
with the structs directly. I haven't used it recently enough to be able to
quote from memory, sorry :/
(and it still makes the correct path harder and harder to figure out over time;
just somewhat less so)
3) bite the bullet and split that in two classes -- no need to subclass TSocket
and TSocketServer, but you probably want to have a TSocketInternals with
TSocketInternalsIPV4, TSocketInternalsUnix, etc.
I'm fond of #3, but it's more work, and may not be preferred by the Powers That
Be. Thoughts?
> Unix domain socket
> ------------------
>
> Key: THRIFT-900
> URL: https://issues.apache.org/jira/browse/THRIFT-900
> Project: Thrift
> Issue Type: New Feature
> Components: C++ - Library
> Environment: Debian GNU/Linux Lenny
> Reporter: Roger Meier
> Fix For: 0.5
>
> Attachments: THRIFT-900_UnixDomainSockets.v2.patch,
> THRIFT-900_UnixDominSockets.patch
>
>
> I would like to use Unix domain sockets.
> client side:
> {code}
> shared_ptr<TSocket> socket(new TSocket("/tmp/ThriftTest.binary.thrift"));
> // as alternative to
> shared_ptr<TSocket> socket(new TSocket(host, port));
> {code}
> server side:
> {code}
> shared_ptr<TServerSocket> serverSocket(new
> TServerSocket("/tmp/ThriftTest.binary.thrift"));
> // as alternative to
> shared_ptr<TServerSocket> serverSocket(new TServerSocket(port));
> {code}
> further enhancement might be:
> use a RFC 3986 compliant URI parser e.g. by using
> http://uriparser.sourceforge.net/ (BSD License)
> and pass a real URI to the constructor, e.g.
> file:///tmp/ThriftTest.binary.thrift
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
