IRC channel logs
2025-02-09.log
back to list of logs
<crupest>Emmm. ps stuck. And I gdb ps. gdb crash with ./gdb/thread.c:1434: internal-error: switch_to_thread: Assertion `thr != NULL' failed.A problem internal to GDB has been detected <crupest>rpctrace gives the problem 44<--50(pid4339)->proc_getprocargs_request (2911) = 0 "/home/crupest/abseil-master/static/bin/absl_stack_consumption_test\0" 231<--230(pid4339)->msg_get_init_port ( 233<--232(pid4339) 4) <crupest>I gdb the unit test and program stuck at signal handler, then I ctrl-c, gdb stuck. Then I ps, ps stuck... <crupest>I killed all stuck unit test processes. Now ps works now. <crupest>I killed gdb. Everything should be back on feet. <crupest>youpi: I have tried now. On linux chroot Debian 14.2.0-16, still 160 just like 12 <youpi>crupest: when ps is stuck you can use -M <crupest>Actually, I just want to get the pid of stuck process. I guess a find /proc/ -type d -exec cat ... /proc/cmdline ... should work also. Just my guess. <gnu_srs>youpi: Regarding 1029097 you should follow all communication: See mails forwarded to bug-hurd. They were not logged in the bug report. <crupest>As for the problem yesterday, I still think our signal handling might pollute the stack. But don't worry, I will try to figure it out myself. <youpi>gnu_srs: which mails? Was Sam in Cc? <youpi>what I see is a re-ask for information by sam on january 16, and svante answered by a mere reopen without any explanation on february 7, so sam rightfully said this is not a way to communicate <youpi>your mail from january 17th was not cc-ed to the list or the bug <youpi>(and I answered why your answer was not actually answering sam's question) <gnu_srs>youpi: Well, take a look at #30, #35 and #42 from 11 Apr 2024 followed by wont-fix in #47 16 Jan 2025. Long processing time indeed and no interest. <gnu_srs>youpi: He is complaining about two tests failing, and totally ignores the rest of the patches. <youpi>Again #30, #35 and #42 do not answer sam's question that I explained: « He didn't ask how they failed, but why, i.e. investigate what that PAM_PERM_DENIED (6) value is coming from, to determine whether it's actually expected to be that error instead of PAM_SYSTEM_ERR (4). » <gnu_srs>Ant the *.install file problem was solved, right? <youpi>because that's debian-only changes <youpi>as I already explained, it's generally better to just discuss with upstream directly <youpi>normally changes should land there anyway <youpi>once a patch is agreed on upstream, it's way easier for the debian maintainer to accept applying until a new upstream version is available <gnu_srs>Well, you knowing everything could have contributed. The bug report was sent 17 Jan 2023, more than two years ago!! <youpi>I can't be the-one-who-fixes-everything-in-the-world <gnu_srs>The Debian maintainers are becoming more and more hostile. Just look at the PATH_MAX discussion. <youpi>that discussion precisely showed quite a few voices against the PATH_MAX constraint, on the contrary <youpi>and at any rate, adding to the hostility cannot solve anything <gnu_srs>I was referring to Sams opinion about PATH_MAX! <youpi>but generalized it to "maintainers", which is not true <youpi>also see his last mail about it <youpi>he rightfully points out that just #define-ing PATH_MAX to an arbitrary value is a poor fix <youpi>and that doing so in the distribution instead of upstream is not the right way <gnu_srs>Never mind, I'm done trying to fix pam :( <etno>I have been sending a patch to netsurf to handle path buffers dynamically (remove all PATH_MAX references), and it never got reviewed. I kind-of understand why they are reluctant to potentially break some code that "works". But it's a bit frustrating :-) <azert>I think that the PATH_MAX issue is the Hurd people being hostile to the rest of the world with a passive aggressive behavior <azert>Decades of code written with PATH_MAX in mind that just works, and needs to be refactored to keep being compatible with the Hurd <youpi>no it most often doesn't work actually <azert>When this condition when it doesn’t work will become relevant, I’m sure it will be fixed regardless the Hurd <youpi>people don't realize that it's already relevant <youpi>they believe that PATH_MAX really is a limit, while it's no <crupest>Limiting PATH_MAX to 4096 is just a way to not actually try to thinkabout the problem, and hide the corresponding bugs. <crupest>"Limiting PATH_MAX to 4096 is just a way to not actually try to thinkabout the problem, and hide the corresponding bugs." <crupest>Actually I don't care about whether there is a limit. But if you say MAX is better than no-MAX, I would disagree. That's just you want to choose which side. <crupest>I mean it is not a concept problem. It is just about compatibility and porting. <azert>I think people just don’t realize that those are bugs <crupest>Speaking about whether MAX or no-MAX is better is kind of meaning-less, especially on security. <crupest>Sorry, but I don't quite understand. What bugs... <azert>The bugs associated with fixing PATH_MAX <azert>btw I’m one of those peoples <azert>If using PATH_MAX is a security concern on Linux, then I’d say this line of thinking is more effective then "this fixes it for me" <azert>Because "this fixes it for me" has an easy answer : fix it on your side <azert>I think it would have been more effective to approach the issue with a mail first reporting the bug and discussing possible approaches on how to fix it <azert>That would have surely received an andwer <azert>Maybe something like: just define PATH_MAX, but still an answer <etno>azert: this is the patch, yes. I discussed the strategy and changed my approach based on this interaction. This approach had some support from some maintainers. I think it simply fell into oblivion. <etno>Because they have more pressing things to do. <crupest>Looks like this is a super big problem of porting. We can't rule upstream and making a standalone fork is so ... <crupest>Oh. I reached the hurd wiki page about this problem. Let me read it <Pellescours>I just got an assertion error in ext2fs/pager.c:413. Something I found strange is that in the previous line (find_block can return err = 0 but *block = 0), so it’s a conflicting case with the assertion <gnu_srs>youpi: Thanks for building 1.7.0-2+hurd.1 on debian-ports :)