尽管讨论指出应该使用 curl 版本 7.32 解决该问题，但即使在带有 gazebo 的 ubuntu 18.04 上使用 curl 版本的 7.52-DEV，我也遇到了崩溃。
使用 gdb 运行凉亭时崩溃的回溯：
*** longjmp causes uninitialized stack frame ***: /home/$USER/gazebo-11.8.1/bin/gzclient terminated
Thread 1 "gzclient" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) backtrace
#0 0x00007ffff5397fb7 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff5399921 in __GI_abort () at abort.c:79
#2 0x00007ffff53e2967 in __libc_message (action=action@entry=(do_abort | do_backtrace), fmt=fmt@entry=0x7ffff550f8fb "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff548db8f in __GI___fortify_fail_abort (need_backtrace=need_backtrace@entry=true, msg=0x7ffff550f8b0 <longjmp_msg> "longjmp causes uninitialized stack frame") at fortify_fail.c:33
#4 0x00007ffff548dbb1 in __GI___fortify_fail (msg=<optimized out>) at fortify_fail.c:44
#5 0x00007ffff548da4d in ____longjmp_chk () at ../sysdeps/unix/sysv/linux/x86_64/____longjmp_chk.S:100
#6 0x00007ffff548d9ab in __longjmp_chk (env=0x7ffff012fb40 <curl_jmpenv>, val=<optimized out>)
at ../setjmp/longjmp.c:39
#7 0x00007fffefec8745 in () at /usr/local/lib/libcurl.so
#8 0x00007ffff5398040 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6
#9 0x00007ffff546dcb9 in __GI___poll (fds=0x555559cbe2f0, nfds=4, timeout=7)
at ../sysdeps/unix/sysv/linux/poll.c:29
#10 0x00007fffed4c56e9 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007fffed4c57fc in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff694a88f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x00007ffff68ef90a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x00007ffff68f89b4 in QCoreApplication::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x00007ffff725a856 in gazebo::gui::run(int, char**) (_argc=<optimized out>, _argv=0x7fffffffb4a8)
at /home/$USER/gazebo-11.8.1/source/gazebo/gui/GuiIface.cc:442
#16 0x00005555555579f4 in main(int, char**) (_argc=1, _argv=0x7fffffffb4a8)
at /home/$USER/gazebo-11.8.1/source/gazebo/gui/main.cc:32
仔细观察崩溃，libcurl.so 在框架 #7 中被访问，然后崩溃最终发生（框架 #6 到 #0）
这种崩溃通常发生在运行 Gazebo 的 15 分钟内，即使程序在空模拟的情况下空闲运行，即模拟中没有加载模型并且没有发生计算，只是 Gazebo 客户端 (gzclient) 正在运行单独与在另一个 shell 上运行的凉亭服务器 (gzserver) 一起运行
在我的 ubuntu 系统中检查 curl 版本（使用 curl --version）时，我得到了
curl 7.52.1-DEV (Linux) libcurl/7.52.1-DEV OpenSSL/1.0.2n zlib/1.2.11
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: IPv6 Largefile NTLM SSL libz UnixSockets HTTPS-proxy
上面的 curl 版本明显高于 7.32 但我还是崩溃了。
用 curl 测试
我删除了 ubuntu 18.04 LTS 默认附带的 curl，并从源代码安装了最新的 curl（版本 7.79.1，截至 17.09.2021）：
git clone https://github.com/curl/curl.git
cd curl
./buildconf
./configure --with-{dict,file,ftp,ftps,gopher,gophers,http,https,imap,imaps,mqtt,pop3,pop3s,rtsp,smb,smbs,smtp,smtps,telnet,tftp}
make
sudo make install
sudo ldconfig
在此之后，我再次运行我的程序并让它在一夜之间运行，这次是模拟在循环中进行计算，持续了 15 多个小时，并且在早上模拟运行。
所以对我来说，新版本的 curl 似乎解决了凉亭崩溃的问题。