core dumped with pico_baton

[Karthikdasari0423]

No token file present. Will create one as <baton_token_store.bin>.
Starting connection to testquic.com, port 8443
Initial connection ID: dc420d3bdda666c0
Waiting for packets.
Segmentation fault (core dumped)
root@ubuntu:~/picoquic#

[huitema]

I have seen issues like that before. Typically a build problem. I suspect that the version of openssl headers used for compiling your version of "picotls" is not the same as the version of openssl binaries linked in the build.

[Karthikdasari0423]

I have installed Openssl only once,just wondering how it be different for picotls and picoquic

[huitema]

I think that when the compiler looks for OpenSSL header files, it finds them at one location, but that when it looks for binary libraries, it finds them at a different location, compiled differently. I have seen that configuration issue happen before.

[huitema]

In any case, can you look at the core file under gdb and list the stack (backtrace, bt)?

[Karthikdasari0423]

Any idea where this core files will be dumped

[huitema]

Simplest way is to just run the program under dbg

[Karthikdasari0423]

Below is the bt,

(gdb) run
Starting program: /root/picoquic/pico_baton 172.16.2.2 8443 172.16.2.2:8443/BPS.pdf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Starting connection to 172.16.2.2, port 8443
Initial connection ID: 30b24871d0bdc93b
Waiting for packets.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff79c6fc2 in __GI__IO_fwrite (buf=0x5555556bc666, size=1, count=157, fp=0x0) at ./libio/iofwrite.c:37
37      ./libio/iofwrite.c: No such file or directory.
(gdb) bt
#0  0x00007ffff79c6fc2 in __GI__IO_fwrite (buf=0x5555556bc666, size=1, count=157, fp=0x0) at ./libio/iofwrite.c:37
#1  0x00005555555b28df in h3zero_callback_client_data ()
#2  0x00005555555b4130 in h3zero_callback ()
#3  0x00005555555a128c in picoquic_stream_data_chunk_callback ()
#4  0x00005555555a3dc7 in picoquic_decode_stream_frame ()
#5  0x00005555555ad087 in picoquic_decode_frames ()
#6  0x00005555555715a4 in picoquic_incoming_1rtt ()
#7  0x000055555557208d in picoquic_incoming_segment ()
#8  0x0000555555572a21 in picoquic_incoming_packet_ex ()
#9  0x000055555558bf10 in picoquic_packet_loop ()
#10 0x000055555555d140 in wt_baton_client ()
#11 0x000055555555cb29 in main ()
(gdb)

[huitema]

@Karthikdasari0423 Does this still reproduce in the recent builds?

Your call to "pico_baton" does not seem right. A bit my fault, there is not a lot of doc, you may want to look inside baton_app.c

If I test against the picoquic test server, I use the calling line:

./pico_baton test.privateoctopus.com 4433 /baton?baton=240

I get the results:

Starting connection to test.privateoctopus.com, port 4433
Initial connection ID: ed1e5568e67ff82d
Waiting for packets.
Received a connection close request
Final baton state: 6
Nb turns: 8
Lane 0, first baton: 0xf0, last sent: 0xff, last received: 0x00
Baton bytes received: 65554
Baton bytes sent: 65552
datagrams sent: 1
datagrams received: 1
datagrams bytes sent: 1401
datagrams bytes received: 1411
Last sent datagram baton: 0x00
Last received datagram baton: 0xf5

[Karthikdasari0423]

okay,will try to test on recent changes

[huitema]

My own tests do not repro this issue. Your calling arguments are erroneous, so I wanted to verify that there was not a bug in the error handling. I reproduced your call, errors and all, as:

./pico_baton  test.privateoctopus.com 4433 172.16.2.2:8443/BPS.pdf

There was no crash, just expected error result:

Starting connection to test.privateoctopus.com, port 4433
Initial connection ID: 8023b28d830b965f
Waiting for packets.
Received a connection close request
Final baton state: 6
Nb turns: 0
Lane 0, first baton: 0x00, last sent: 0x00, last received: 0x00
Baton bytes received: 0
Baton bytes sent: 0
datagrams sent: 0
datagrams received: 0
datagrams bytes sent: 0
datagrams bytes received: 0
Last sent datagram baton: 0x00
Last received datagram baton: 0x00

This, and your stack dump, confirm my initial suspicion of an OpenSSL issue. The top of your stack trace says:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff79c6fc2 in __GI__IO_fwrite (buf=0x5555556bc666, size=1, count=157, fp=0x0) at ./libio/iofwrite.c:37
37      ./libio/iofwrite.c: No such file or directory.
(gdb) bt
#0  0x00007ffff79c6fc2 in __GI__IO_fwrite (buf=0x5555556bc666, size=1, count=157, fp=0x0) at ./libio/iofwrite.c:37
...

This is a crash in openssl -- in an IO call. This will happen if openssl was not build properly, which is unlikely, or if picotls was build against a different version of openssl, which is thus the most likely. I think that you have two versions of openssl in your system. When picotls is built, the build process finds the header files of one version. When pico_baton is run, the dynamic linker finds a shared library of a different version. Some calling arguments have changed. Misaligned calling lists will cause the crash that you observe.