04-21-2021, 04:18 PM (This post was last modified: 04-22-2021 09:07 AM by 3298.)
Post: #1
 3298 Member Posts: 179 Joined: Oct 2014
I recently ran into a glibc bug, but there's a little something in the bug tracker's registration procedure that prevents me from reporting it.
Quote:Activity on most bugs, including email addresses, will be visible.
(Emphasis mine.) Exposing private info like a mail address is where the fun stops - no way I'll register there. This forum, by contrast, lets me hide my mail address, just like many other places on the web do. Even public git repositories technically don't need an address that actually accepts mail, a no-reply or invalid one generally works fine.
Privacy rant aside, I'd still like to get the bug fixed. I do have a patch ... That means I now need someone who's less concerned about privacy to forward a bug report. I'm not as picky about attribution for the discovery and the fix - when you know what's going wrong, it's just a trivial two-liner anyway. Details follow, in a format that should make it easy to simply insert into the bug template (though maybe the two code boxes could be supplied as attached files instead of or in addition to inline text):

Product: glibc

OS: All

Summary: Inconsistency detected by ld.so: dl-fini.c: 88: _dl_fini: Assertion ns != LM_ID_BASE || i == nloaded' failed!

Description:

Overview:
The dynamic linker's finalizer crashes if it's not (directly or indirectly) in the library dependencies of the loaded application.

Steps to reproduce:
Compile and run a self-contained program calling the dynamic linker's finalizer (received in %rdx on x86-64 according to the ABI docs) before exit, with link options specifying that a dynamic linker shall be used, but without linking to something that pulls in the dynamic linker itself (be careful: libc.so.6 does), e.g. with these GCC options: -nostdlib -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2
Code:
# filename: dl_fini_assert_nloaded_test.S #include <asm/unistd_64.h>     .text     .globl    _start     .type    _start, @function _start:     test %rdx, %rdx    # this register is where the dynamic linker's finalizer             # address is passed, can be $0 if none exists jz .no_dl_fini call *%rdx .no_dl_fini: mov$0, %edi     mov __NR_exit, %eax     syscall

Actual Results:
Crash, with the assertion failure message listed above.

Expected Results:
Clean exit.

Build Date & Hardware:
2021-04-21 on Arch Linux
- glibc version: 2.33 (as tested; should affect every version since 2.2)
- kernel: Linux 5.11 (as tested; should not matter for the glibc code, but my test case assumes Linux for the exit syscall and for the linker options)
- architecture: x86-64 (as tested; should not matter for the glibc code, but my assembly test case clearly needs it)
- compiler and linker versions: GCC 10.2.0, ld 2.36.1 (as tested; shouldn't matter for the glibc code, but my test case is written with GCC in mind)

I tracked this issue down to where the rtld function dl_main temporarily adds the rtld itself to the list of loaded libraries, then removes it later if it's not in the dependencies of other libraries loaded in the meantime. libc.so.6 does have such a dependency, so this code path is rarely used, because almost all software uses the shared version of the C standard library in some way or is statically linked (in the latter case, the rtld generally isn't used to launch the software in the first place). The bug is simply that during removal the counter for loaded objects isn't decremented. This mismatch then gets noticed when the rtld finalizer is called, triggering an assertion.
The bug exists since commit 1ebba33ece5a998d3d79fa14adca3ae7985cbff5 made way back in August 2000, which introduced this counter. There are sporadic occurences of the crash message on the web, e.g. in the FreePascal bug tracker, but apparently nobody went the extra mile to properly report or fix it.
Code:
# filename: dl_fini_assert_nloaded_fix.diff diff --git a/elf/rtld.c b/elf/rtld.c index 94a00e2049..849a449e77 100644 --- a/elf/rtld.c +++ b/elf/rtld.c @@ -2007,6 +2007,8 @@ dl_main (const ElfW(Phdr) *phdr,        GL(dl_rtld_map).l_next->l_prev = &GL(dl_rtld_map);      }      } +  else +    --GL(dl_ns)[LM_ID_BASE]._ns_nloaded;      /* Now let us see whether all libraries are available in the       versions we need.  */

Attached File(s)
04-21-2021, 05:02 PM
Post: #2
 rprosperi Super Moderator Posts: 5,197 Joined: Dec 2013
RE: Inconsistency detected by ld.so: dl-fini.c: 88: _dl_fini: Assertion [...] failed!
Which "Not remotely an HP Calculator" machine or program is this about?

--Bob Prosperi
04-21-2021, 05:11 PM
Post: #3
 SammysHP Member Posts: 151 Joined: Jul 2018
RE: Inconsistency detected by ld.so: dl-fini.c: 88: _dl_fini: Assertion [...] failed!
And why haven't you used another mail address? That's not a "one per person" thing and you can have as many as you want.
04-21-2021, 06:36 PM
Post: #4
 3298 Member Posts: 179 Joined: Oct 2014
RE: Inconsistency detected by ld.so: dl-fini.c: 88: _dl_fini: Assertion [...] failed!
(04-21-2021 05:02 PM)rprosperi Wrote:  Which "Not remotely an HP Calculator" machine or program is this about?
glibc on basically any Linux (or similar) desktop and laptop, obviously. I mean, read the section titled "Build date & Hardware"...
Counter-question: Which other category should this have gone into? It's not an HP calculator, so this doesn't fit into "General Discussion"; and despite the ability to run emulators or simulators of these, I don't think it qualifies for "Not quite", so into the "Not remotely" category it goes.
(04-21-2021 05:11 PM)SammysHP Wrote:  And why haven't you used another mail address? That's not a "one per person" thing and you can have as many as you want.
At what price? Because I haven't found a mail provider besides the university one which is compatible with both my wallet and the same privacy concerns. And the university mailer is - surprise! - one account per person.
Feel free to suggest one, though. I just don't think you'll find any.
04-21-2021, 07:16 PM
Post: #5
 Thomas Okken Senior Member Posts: 1,725 Joined: Feb 2014
RE: Inconsistency detected by ld.so: dl-fini.c: 88: _dl_fini: Assertion [...] failed!
(04-21-2021 06:36 PM)3298 Wrote:  Counter-question: Which other category should this have gone into? It's not an HP calculator, so this doesn't fit into "General Discussion"; and despite the ability to run emulators or simulators of these, I don't think it qualifies for "Not quite", so into the "Not remotely" category it goes.

Not only is this not remotely about HP calculators, it's not remotely about calculators at all. This is a Linux programming topic, it should go in a Linux programming forum.

(04-21-2021 06:36 PM)3298 Wrote:  Because I haven't found a mail provider besides the university one which is compatible with both my wallet and the same privacy concerns. And the university mailer is - surprise! - one account per person.
Feel free to suggest one, though. I just don't think you'll find any.

Gmail. If you're concerned about Google snooping, then don't use the account for anything snoop-worthy.
04-21-2021, 08:06 PM
Post: #6
 3298 Member Posts: 179 Joined: Oct 2014
RE: Inconsistency detected by ld.so: dl-fini.c: 88: _dl_fini: Assertion [...] failed!
(04-21-2021 07:16 PM)Thomas Okken Wrote:  Not only is this not remotely about HP calculators, it's not remotely about calculators at all. This is a Linux programming topic, it should go in a Linux programming forum.
Maybe. I just figured that with the programmers frequenting this place, and with even lock-picking discussed in this sub-forum, it fit well enough to be worth trying. And this place didn't require a new account to boot.

(04-21-2021 07:16 PM)Thomas Okken Wrote:  Gmail. If you're concerned about Google snooping, then don't use the account for anything snoop-worthy.
... like using it as the mail address on a new account, basically tying control of that account to the mail one? That's the crux here, isn't it... there just isn't anything left if you exclude anything snoop-worthy. The old "I've got nothing to hide" - "Yes, you definitely do" discussion comes to mind.
Anyway, stuff from advertising giants like Google is pretty high on my never-use list. Just the possibility to connect usage data from that to data they get about me from somewhere else is too much, and that's without factoring in Google's bad privacy reputation.
04-22-2021, 12:30 AM
Post: #7
 rprosperi Super Moderator Posts: 5,197 Joined: Dec 2013
RE: Inconsistency detected by ld.so: dl-fini.c: 88: _dl_fini: Assertion [...] failed!
(04-21-2021 06:36 PM)3298 Wrote:
(04-21-2021 05:02 PM)rprosperi Wrote:  Which "Not remotely an HP Calculator" machine or program is this about?
glibc on basically any Linux (or similar) desktop and laptop, obviously. I mean, read the section titled "Build date & Hardware"...
Counter-question: Which other category should this have gone into? It's not an HP calculator, so this doesn't fit into "General Discussion"; and despite the ability to run emulators or simulators of these, I don't think it qualifies for "Not quite", so into the "Not remotely" category it goes.

I guess it isn't obvious, since one should reasonably expect a post here to be about a calculator, or calculator-related topic, or at least say that it isn't if not. I agree some fairly OT posts are made here, and that's fine, but they typically do identify themselves as OT, or sometimes it's clear from the topic.

I'd guess that dozens of calculator-software projects include a glib.c, so it appeared you simply forgot to include which machine or program this applies to, as that seems more likely than it was completely unrelated.

I think this is indeed the right place to post it, among the choices here, but would suggest it helps to note that it's OT when it's somewhat wide of the core topics. I don't think Linux programming is core to a majority of the folks here, though more than just a few is surely the case.

--Bob Prosperi
04-22-2021, 07:40 AM
Post: #8
 EdS2 Senior Member Posts: 369 Joined: Apr 2014
RE: Inconsistency detected by ld.so: dl-fini.c: 88: _dl_fini: Assertion [...] failed!
Yes, I think a re-title would be a good idea, and enough:
OT: help please with filing a bug (I have privacy concerns)

I have in the past used email addresses from mailinator, which are free and anonymous, but there are limitations and of course sometimes these addresses are not considered acceptable.
04-22-2021, 09:05 AM (This post was last modified: 04-22-2021 10:23 AM by 3298.)
Post: #9
 3298 Member Posts: 179 Joined: Oct 2014
RE: Inconsistency detected by ld.so: dl-fini.c: 88: _dl_fini: Assertion [...] failed!
(04-22-2021 07:40 AM)EdS2 Wrote:  Yes, I think a re-title would be a good idea, and enough:
OT: help please with filing a bug (I have privacy concerns)
Fiiine, I'll take a tweaked version (+"against glibc") of your suggested title. I wanted to make it so people who are unable to handle the crash message skip this thread, but apparently that didn't work, they came in anyway.

(04-22-2021 07:40 AM)EdS2 Wrote:  I have in the past used email addresses from mailinator, which are free and anonymous, but there are limitations and of course sometimes these addresses are not considered acceptable.
... usually considered unacceptable for good reason, since they practically cede control of an account to whoever hits the password recovery button first and then fetches the publicly accessible mail sent in response. It's not like these trash-mail providers have no uses, but I think this isn't it.

---

So, since the forum people demand a connection to HP calculators, have a tease of the project this bug came up in. The project is a long way from anything more than that though. I hope your SysRPL is good enough to see the similarities and differences.
Code:
$cat helloworld.obf : main # 4097 # 4093 # 3 # 2 {}N >R BEGIN tic2R WHILE #- REPEAT "Hello " "World!\n" ' &$ EVAL SWAP DUP DROP write ; $make helloworld ./obfc -o=helloworld.o helloworld.obf ld -pie -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o helloworld helloworld.o -L. -lobf$ ./helloworld Hello World! Inconsistency detected by ld.so: dl-fini.c: 88: _dl_fini: Assertion ns != LM_ID_BASE || i == nloaded' failed! \$
The random-looking collection of commands is primarily a rudimentary test for proper function of these commands - and a showcase on the side.
04-22-2021, 12:47 PM
Post: #10
 Liam Hays Member Posts: 55 Joined: Jan 2021
Quote:... like using it as the mail address on a new account, basically tying control of that account to the mail one? That's the crux here, isn't it... there just isn't anything left if you exclude anything snoop-worthy. The old "I've got nothing to hide" - "Yes, you definitely do" discussion comes to mind.

Also, I don't see what's wrong with posting about this here. This forum is incredibly friendly and willing to help, from everything I've seen, and I'm sure there are many Linux programmers here (including myself).
04-22-2021, 03:14 PM
Post: #11
 Thomas Okken Senior Member Posts: 1,725 Joined: Feb 2014
(04-21-2021 08:06 PM)3298 Wrote:
(04-21-2021 07:16 PM)Thomas Okken Wrote:  Gmail. If you're concerned about Google snooping, then don't use the account for anything snoop-worthy.
... like using it as the mail address on a new account, basically tying control of that account to the mail one? That's the crux here, isn't it... there just isn't anything left if you exclude anything snoop-worthy. The old "I've got nothing to hide" - "Yes, you definitely do" discussion comes to mind.
Anyway, stuff from advertising giants like Google is pretty high on my never-use list. Just the possibility to connect usage data from that to data they get about me from somewhere else is too much, and that's without factoring in Google's bad privacy reputation.

Nobody said anything about "nothing to hide."

Create a Gmail account for use with that bug tracker. And don't use that Gmail account for anything else. What's the problem?
04-22-2021, 04:46 PM
Post: #12
 cdmackay Senior Member Posts: 636 Joined: Sep 2018
This is quite a relevant issue to Linux development, given the controversy over the University of Minnesota's research, at the moment: https://www.theregister.com/2021/04/21/m...ws_update/

I mention this since it's relevant here: Linux kernel development (at least) is done almost exclusively via email, and the above issue raises many issues of trust, identification, reputation, audit, etc.

Attempting to get involved in that sort of development anonymously is moving in the opposite direction, obviously, and so not something to recommend.

Cambridge, UK
41CL/DM41X 12/15C/16C DM15/16 71B 17B/BII/bII+ 28S 42S/DM42 32SII 48GX 50g 35s 30b/WP34S Prime G2
& Casios, Rockwell 18R :)
04-22-2021, 05:30 PM
Post: #13
 cruff Member Posts: 223 Joined: Dec 2013
Remember that the GNU glibc effort is not the Linux kernel development effort.
04-23-2021, 12:48 AM
Post: #14
 mfleming Senior Member Posts: 769 Joined: Jul 2015
I've been following this thread with a bit of bemusement. My initial impression of the OP's request (still held) is that he's asking someone else to do what he himself considers unsafe and inadvisable. I don't mean to be critical in any way, but the request resembles

"I"ve just discovered a landmine in my backyard that I'd like to be rid of, but I don't want to be blown up by stepping on it." To his neighbors "Would one of you mind stepping on it for me? No need to credit me with finding it if you wish."

Silly example, but that was my immediate impression of the request

Remember kids, "In a democracy, you get the government you deserve."
04-23-2021, 07:27 AM
Post: #15
 EdS2 Senior Member Posts: 369 Joined: Apr 2014
I see it as more harmless than that. Someone laid up with a leg in plaster wondering if you could bring some milk back from your walk past the shops.

We should understand that different people have different levels of concern about things, including privacy, tracking, and all the rest.

It is still merely a request for assistance: no-one is obligated to assist or need feel troubled that they don't wish to help.

This is mostly a helpful forum, but we all have bad days, and making the title as informative as possible is probably a useful tactic. I'm not sure we see much use of "OT" here, as a prefix to signpost something offtopic, but I've seen it used elsewhere to good effect. It makes a topic easy to ignore, and also gives a sense of how few off-topic threads there are.

This thread is really a 'nothing to see here, move on' unless you happen to be a helpful bug-filer by disposition. And I think that's fine.
04-23-2021, 11:03 AM
Post: #16
 3298 Member Posts: 179 Joined: Oct 2014
If you insist on the landmine analogy, please pay attention to how I asked for a weapons disposal expert, not just any neighbor: "I now need someone who's less concerned about privacy". Because there literally are people who get paid for defusing and disposing of landmines. It's not a job for everyone, but priorities are different for different people, just like in this privacy case.

Stretching the mine analogy further, trying to circumvent the issue using GMail is like dropping a small nuclear bomb on it. It makes the landmine vanish, but you've just swapped the explosive problem for nuclear fallout stretching all the way to other Google services that I cannot avoid using, like the captchas that occasionally pop up in random corners of the internet, or other Google APIs which are required to make some 3rd-party websites work.

ProtonMail is a mine defusing checklist, which is much more up my alley - I can do it myself, but it's not perfect either. One account per person allowed, only one address per account unless I pay up, can't use ordinary mail clients like KMail or Thunderbird unless I pay up ... so using that is a bit cumbersome (that I could deal with), and would mean locking myself out of migrating there after I leave the university, which I also need to look into at some point. Still, thanks for the suggestion.

All that is moot though, because an explosives expert has picked up my call: while you guys were quibbling over privacy and mail services and mail addresses, I received a message with the offer to forward the bug report - pretty much exactly what I was looking for. I'm not gonna name the person here, this was a private message after all; this leaves the decision whether to associate a forum user name with the offer to the affected person. That's the least I can do to respect others' privacy.

Now that the privacy angle has been discussed to death: neighbors, can we please preemptively evacuate the blast zone together and prepare the nearby road for landmine transport - I mean, get back to the technical issue of ld.so falling flat on its face under certain circumstances?

(04-23-2021 07:27 AM)EdS2 Wrote:  This thread is really a 'nothing to see here, move on' unless you happen to be a helpful bug-filer by disposition.
Bingo, that's what I was going for with the thread title - both versions of it. With less than optimal results, unfortunately.
04-23-2021, 08:58 PM
Post: #17
 cdmackay Senior Member Posts: 636 Joined: Sep 2018
(04-22-2021 05:30 PM)cruff Wrote:  Remember that the GNU glibc effort is not the Linux kernel development effort.

of course, which is why I added "at least" above. But I'm assuming it's broadly similar.

Cambridge, UK
41CL/DM41X 12/15C/16C DM15/16 71B 17B/BII/bII+ 28S 42S/DM42 32SII 48GX 50g 35s 30b/WP34S Prime G2
& Casios, Rockwell 18R :)
04-24-2021, 02:44 PM (This post was last modified: 04-24-2021 06:22 PM by Maximilian Hohmann.)
Post: #18
 Maximilian Hohmann Senior Member Posts: 961 Joined: Dec 2013
Hello!

(04-23-2021 11:03 AM)3298 Wrote:  Now that the privacy angle has been discussed to death...

Have you found someone yet who is filing the bug for you? If not, I volunteer. My E-Mail address (and street address and phone number...) have been visible on the net since 20 years, because I am in charge of our horse-riding-club domain and german law requires that the domain holder's details must be listed in the imprint. So far this has not generated any unusual spam or strange phone calls or even horse-specific adverts from google, so my conclusion is that the consequences of e-mail harvesting on the net are grossly overrated.

Just let me know.

Regards
Max
04-24-2021, 05:53 PM (This post was last modified: 04-24-2021 05:55 PM by 3298.)
Post: #19
 3298 Member Posts: 179 Joined: Oct 2014
I did find somebody, actually. The bug has been officially filed yesterday, but no response yet. (Not that I expected one so quickly.)

The prevalence of real names or mail addresses used as usernames on this forum was what I was banking on - I hoped that one of you would play the "too late for privacy anyway" card, and now I actually got two of you. You may have noticed that I use a pseudonym instead ... I think that's a result of growing up when the internet was a thing already (I believe I'm younger than most of you by quite a margin: <30), as well as having a rare first name, rare last name, and globally unique combination of these. Such things made me value privacy more.

That said, my real name is on the internet (e.g. in a local newspaper's digital archive) ... just not associated with my online activities and the online identities (yes, plural) connected to them.

Thanks you very much for the offer though.
04-24-2021, 06:40 PM (This post was last modified: 04-24-2021 07:57 PM by Maximilian Hohmann.)
Post: #20
 Maximilian Hohmann Senior Member Posts: 961 Joined: Dec 2013
Hello!

(04-24-2021 05:53 PM)3298 Wrote:  You may have noticed that I use a pseudonym instead ... I think that's a result of growing up when the internet was a thing already (I believe I'm younger than most of you by quite a margin: <30)...

Interesting. I usually have the impression that it is rather the other way round. Lots of young people who grow up with Facebook, Twitter, YouTube, ... don't seem to care the least about discharging their whole existence onto the world, whereas most people over 50 that I know do not even have social media accounts and would rather cut off both their hands than to register with Facebook (me included) ;-)

Regards
Max
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)