{"id":159,"date":"2022-07-29T01:23:06","date_gmt":"2022-07-29T01:23:06","guid":{"rendered":"https:\/\/blogs.gentoo.org\/gsoc\/?p=159"},"modified":"2022-07-29T01:23:06","modified_gmt":"2022-07-29T01:23:06","slug":"daily-blog-july-28-by-catcream","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/gsoc\/2022\/07\/29\/daily-blog-july-28-by-catcream\/","title":{"rendered":"Daily blog july 28 by Catcream"},"content":{"rendered":"<p>Today worked on some different things. The first one was making another libexecinfo based on libunwind. The issue was that the current libexecinfo (resslinux\/libexecinfo on github) sometimes segfaults. For me it segfaulted when emerging Emacs because temacs (Emacs bootstrap) used it, and I think it backtraced too far (into libc). After reading some GitHub issues\/ML posts it seemed like everyone recommended libunwind instead, and there were some issues with libexecinfo due to __builtin_frame_address. Because the execinfo interface is so simple: basically one function that returns a list of pointers to previous function calls, and two other functions that retrieves the symbol names for these addresses, I thought it would be neat to just use libunwind for the backtrace()-function (the one that returns list of ptrs) and then just copy paste the symbol lookup funcs. I tried it and it &#8220;just works&#8221; without the __builtin_* hackery! The current version is improved over libexecinfo in 4 ways:<\/p>\n<ol>\n<li>Uses meson so that a .pc file gets generated automatically.<\/li>\n<li>Doesn&#8217;t generate source files with a Python script (https:\/\/github.com\/resslinux\/libexecinfo\/blob\/master\/gen.py).<\/li>\n<li>\u00a0Doesn&#8217;t segfault (yay).<\/li>\n<li>Includes various fixes for backtrace_symbols https:\/\/git.alpinelinux.org\/aports\/tree\/main\/libexecinfo\/10-execinfo.patch.<\/li>\n<\/ol>\n<p>ebuild: https:\/\/github.com\/alfredfo\/catcream_repo\/blob\/master\/sys-libs\/libexecinfo\/libexecinfo-1.0.0.ebuild<br \/>\nsource: https:\/\/github.com\/alfredfo\/libexecinfo-unw<\/p>\n<p>see: https:\/\/github.com\/mikroskeem\/libexecinfo\/issues\/2, https:\/\/www.openwall.com\/lists\/musl\/2019\/08\/22\/2.<\/p>\n<p>I&#8217;ve also learnt how to set up clean musl build systems with ebuildtester.<br \/>\nExample: <code>ebuildtester --portage-dir \/home\/cat\/gentoo --atom sys-process\/htop --docker-image gentoo\/stage3:musl<\/code><br \/>\nSpent some time with Docker images before I realized that there was already a gentoo\/stage3:musl image ready.<\/p>\n<p>I have continued to research the Konsole test thing from monday. The TerminalInterfaceTest only fails when using zsh and ebuild konsole-ver.ebuild test (not executing test manually). I still don&#8217;t know really what causes it but when using bash it works.<\/p>\n<p><code>currentDirectory = QStringLiteral(\"\/tmp\");<br \/>\nterminal-&gt;sendInput(QStringLiteral(\"cd\") + currentDirectory + QLatin1Char('\\n')); &lt;- THIS<br \/>\nstateSpy.wait(2000);<br \/>\nQCOMPARE(stateSpy.count(), 1);<\/code><\/p>\n<p>This code fails, but changing it to<br \/>\n<code>currentDirectory = QStringLiteral(\"\/tmp\");<br \/>\nterminal-&gt;sendInput(QStringLiteral(\"\\ncd\") + currentDirectory + QLatin1Char('\\n'));<br \/>\nstateSpy.wait(2000);<br \/>\nQCOMPARE(stateSpy.count(), 1);<\/code><br \/>\nor<br \/>\n<code>currentDirectory = QStringLiteral(\"\/tmp\");<br \/>\nterminal-&gt;sendInput(QStringLiteral(\";cd\") + currentDirectory + QLatin1Char('\\n'));<br \/>\nstateSpy.wait(2000);<br \/>\nQCOMPARE(stateSpy.count(), 1);<\/code><\/p>\n<p>works just fine. Really weird! It acts like there&#8217;s some garbage text inputted at the start.<\/p>\n<p>I also never posted anything yesterday because I was up really late working on gsoc and just went to sleep :). Yesterday I messed around with Emacs to figure out the libexecinfo bug and I also looked into how to use libunwind, which got me the idea to implement libexecinfo using it. I also spent some time with the Konsole test thing.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Today worked on some different things. The first one was making another libexecinfo based on libunwind. The issue was that the current libexecinfo (resslinux\/libexecinfo on github) sometimes segfaults. For me it segfaulted when emerging Emacs because temacs (Emacs bootstrap) used &hellip; <a href=\"https:\/\/blogs.gentoo.org\/gsoc\/2022\/07\/29\/daily-blog-july-28-by-catcream\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":177,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/posts\/159"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/users\/177"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/comments?post=159"}],"version-history":[{"count":3,"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/posts\/159\/revisions"}],"predecessor-version":[{"id":162,"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/posts\/159\/revisions\/162"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/media?parent=159"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/categories?post=159"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/tags?post=159"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}