[
https://issues.apache.org/jira/browse/THRIFT-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16764407#comment-16764407
]
James E. King III commented on THRIFT-4533:
-------------------------------------------
You said framed, but in your stack the multiplexed protocol is using binary
protocol to read the size. Did you align the protocols properly on both sides?
> C Framed transport causes sigsev from time to time
> --------------------------------------------------
>
> Key: THRIFT-4533
> URL: https://issues.apache.org/jira/browse/THRIFT-4533
> Project: Thrift
> Issue Type: Bug
> Components: C glib - Library
> Affects Versions: 0.10.0
> Reporter: Gonzalo Aguilar
> Priority: Major
>
> It seems that from time to time Apache Thrift receives a package that doesn't
> complies with what's expected and it causes a sigsev.
> It happens reading the frame.
>
> {{Thread #1 [sg64_hardware_m] 14184 [core: 22] (Suspended : Signal :
> SIGSEGV:Segmentation fault) }}
> {{ thrift_framed_transport_read_frame() at
> /home/gaguilar/thrift/thrift/lib/c_glib/src/thrift/c_glib/transport/thrift_framed_transport.c:98
> 0x7ffff7bc9bbd }}
> {{ thrift_framed_transport_read_slow() at
> /home/gaguilar/thrift/thrift/lib/c_glib/src/thrift/c_glib/transport/thrift_framed_transport.c:134
> 0x7ffff7bc9c3f }}
> {{ thrift_transport_real_read_all() at
> /home/gaguilar/thrift/thrift/lib/c_glib/src/thrift/c_glib/transport/thrift_transport.c:122
> 0x7ffff7bc6004 }}
> {{ thrift_binary_protocol_read_i32() at
> /home/gaguilar/thrift/thrift/lib/c_glib/src/thrift/c_glib/protocol/thrift_binary_protocol.c:712
> 0x7ffff7bc27ee }}
> {{ thrift_binary_protocol_read_message_begin() at
> /home/gaguilar/thrift/thrift/lib/c_glib/src/thrift/c_glib/protocol/thrift_binary_protocol.c:410
> 0x7ffff7bc20b0 }}
> {{ thrift_multiplexed_processor_process_impl() at
> /home/gaguilar/thrift/thrift/lib/c_glib/src/thrift/c_glib/processor/thrift_multiplexed_processor.c:83
> 0x7ffff7bbf38b }}
> {{ thrift_simple_server_serve() at
> /home/gaguilar/thrift/thrift/lib/c_glib/src/thrift/c_glib/server/thrift_simple_server.c:58
> 0x7ffff7bcac25 }}
> {{ main() at
> /home/gaguilar/workspace-c/moverick-hardware-monitor/src/sg64_hardware_monitor_main.c:254
> 0x555555557dd3 }}
>
>
> {{}}{{transport ThriftTransport * 0x555555825440 }}
> {{transport@entry ThriftTransport * 0x555555825440 }}
> {{error GError ** 0x7fffffffca60 }}
> {{error@entry GError ** 0x7fffffffca60 }}
> {{tmpdata guchar * 0x7fffe9fcc760 <error: No se puede acceder a la
> memoria en la dirección 0x7fffe9fcc760> }}
> {{t ThriftFramedTransport * 0x555555825440 }}
> {{sz guint32 369295616 }}
> {{bytes gint32 <optimized out> }}
> {{result gboolean 0 }}
>
> As can be seen it's requesting about 370Mb. So I suppose it's a spurious
> message that arrived over wire. Maybe a port scanning. I have reports that it
> happens even when nothing is connected to the wire. Something it seems
> strange to me.
>
> I cannot see how may bytes are read because compiler optimized it. But I can
> see that it looks like system allocated that memory into tmpdata. What seems
> weird is that compiler cannot access that memory direction. So I wonder if
> that address is wrong and causing the sigsev.
>
> A possible patch is to know in advance how many bytes a package can have, and
> therefore set a limit to what we can allocate and read. The problem is that
> we must know about the upper layers something that breaks a little bit the
> layered design.
>
> What do you think?
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
