IRC channel logs
2025-02-08.log
back to list of logs
<crupest>Do we really need PAM? Isn't it specific to Linux? <Arsen>perhaps the most useful part of it is that everything else that uses it works better with it present ;P <Arsen>(no = not specific to linux) <crupest>There is a mail in debian mailing list. It says a problem of pam waiting us to deal with. <crupest>Though I have not read it carefully. Will read it later to see if I can fix. <crupest>OK. I'm nearly done with abseil. Sort the patch now. <youpi>Svante's communication on this was indeed not really good, by not answering Sam's questions and just reopening without a single comment, which is rude <crupest>I'm struggling about the stack memory consumption problem in abseil. <crupest>With sigstack, is our signal handler always called in the same situation? I mean the same stack frames, address not changes. <crupest>It uses a very tricky way to do that. <crupest>mmap a buffer, swipe it a random value 0x55. Set a SIGUSR1 to a empty handler. send it and scan reversed. Count until not 0x55. <crupest>The set SIGUSR2 to the real signal handler. Do it again. <crupest>Then minus these two to get the stack memory used by the signal handler. <crupest>The test handler has a char buffer[100]. <crupest>However I disable optimization of the two handlers, it never be 100 or more. <crupest>Sorry. I said wrong. I mean use whatever the same way I do it on Linux <crupest>Unless I use __attribute__((optimize("O0"))) to disable both. <crupest>Whatever, I'm messed with the data. In one word, Linux never less than 100. While ours must be strictly avoided optimization, then it can be >= 100 <crupest>It might be the compiler really optimized it very much. Or the way to measure is not feasible to us. <youpi>crupest: arbitrary 100 looks wrong to me, they should use much more, to be somehow sure to catch things <youpi>I'm not sure about SIGUSR2: is that raised from the SIGUSR1 handler? <youpi>or is it just getting SIGUSR1 handled, and then SIGUSR2? <youpi>but then why should addresses be different? <youpi>I don't see why there should be any difference <crupest>The problem is the function defines a char buffer[100]. <crupest>While calculate it in this way, it is less than 100. <crupest>I wonder this is natural for compiler optimization. <crupest>Or this method is just wrong. So the result is also wrong . <crupest>However, Linux does not suffer from optimiazation problem. It's always > 100, about 160. <crupest>I remember at the beginning without modification of upstream code, the test result is 96 <crupest>The assertion of the test is >= 100. <crupest>I have sent the mails now to debian list. <youpi>ah I see, it's trying to make sure that the buffer is printed <youpi>err, but it's invalid actually <youpi>it doesn't put a trailing \0 <crupest>The print is to avoid optimization... <youpi>so actually a compiler would be right in assuming that it's not actually to be executed <youpi>yes, by "printed", I meant "not optimized away" actually <crupest>Because it does not know signo will never be 0. <youpi>yes, but buf is not a valid string <youpi>it doesn't have a trailing \0 <youpi>I'd say try to put a trailing \0 <youpi>setting optimize 0 to EmptySignalHandler should n't be needed <crupest>This is a signal handler. So signo will never be 0. <youpi>for SimpleSignalHandler, please post the resulting assembly so we can check what actually happen <crupest>However, compiler does not know this <youpi>but it knows that buf is not a valid string <youpi>concerning test_helpers, I believe you should n't put ifdef __GNU__ <youpi>including signal.h makes sense for all OSes <crupest>youpi: I just want the abseil team to decide. <crupest>Actually, this is against google coding style. <crupest>They must rely on some indirect including. <youpi>so they should just include it to get SIGABRT <crupest>As for the assembly, the assembly of the original function is very long. <crupest>The function finnal call into the c++ function. <crupest>When it is expanded, there are a lot of function calling. <crupest>Wait a moment for me to get the assembly <youpi>I've posted a mail to summarize what we said here <crupest>By invalid string, do you mean compiler see it as undefined behavior and does whatever it wants? <youpi>that's the most plausible explication I can see in not actually filling 100 bytes on the stack <crupest>I can't find a pastebin that accepts large file... <youpi>yes, that should compress fine :) <youpi>but is the function itself that large ? <crupest>And the pastebin can't put binary like .gz <youpi>so it does seem it really puts 100 bytes <youpi>it's odd that that doesn't get detected <youpi>was this with your -O0 trick? <youpi>well it does indeed store 100 bytes <crupest>However, I add buf[99] = '\0'. It's still 96 <youpi>possibly 0x55 happens to get put on the stack by the signal management, just by misluck <youpi>(i.e. overwriting a part of the buf) <youpi>and setting -O0 just shifts the buffer a bit, making the test work just by luck <crupest>BTW, the compiler options: -O2 -fstack-protector-strong <youpi>ok, now I see the idea behind the test, just adding a buffer in the function and see the corresponding stack usage increase <youpi>that however looks very fragile to me <youpi>and setting optimizations to 0 seems very sane to me actually <youpi>because you can never know what the compiler could be doing with an empty function vs a function with some buffer <youpi>on linux and hurd, are you using the same compiler version? <youpi>linux being about 160 is actually most probably sheer luck <youpi>it could very well be 96 as well <crupest>hurd:linux upstream: 96:160 my: 104:160 <crupest>g++: (Debian 14.2.0-13) 14.2.0 vs (Debian 12.2.0-14) 12.2.0 <youpi>maybe try the same version on linux <crupest>Can I just compile the two .cc. I think I can... <crupest>Looks like I have to go to unrelease version of debian to install 14 <youpi>it's available in testing & unstable yes <youpi>you can use a chroot for that <crupest>I have to rest now. I'll continue tomorrow. Thanks! <crupest>You have not seen what the empty signal handler is like in assembly. <crupest>Another one. Assembly of my code. We just read the upstream one. <crupest>The empty handler now moved into GOT <youpi>oh, the function is not static? <crupest>In my code, there is no LOG, so SimpleSignalHandler is much shorter. <crupest>I was originally wanting to use gdb to debug the address. But it can't break at the real handler. So I failed.