[PATCH] dtprobed: use /proc/$pid/map_files, not the filename of the mapping

[PATCH] dtprobed: use /proc/$pid/map_files, not the filename of the mapping

[Nick Alcock]

When hunting down a text mapping, prf->prf_mapname is equivalent to
looking at the symlink target of the /proc/$pid/map_files/* file, so
opening that opens (say) /usr/bin/blah. If we use Pmap_mapfile_name()
instead, we get the name of the actual /proc/$pid/map_files file
itself. This looks like a symlink, but it's actually magic: it points to
the target of the mapping even if that target is in a different
filesystem namespace, and you can dereference and open it to get the
contents of the mapping even if the symlink is apparently "broken".
DTrace already uses this elsewhere in USDT probe lookup, so we can
surely use it here as well.

Fixes e.g. running programs with probes out of /home (which is jailed
away from dtprobed by dtprobed's systemd service file).

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
---
 dtprobed/dtprobed.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dtprobed/dtprobed.c b/dtprobed/dtprobed.c
index a808586559d96..9a6928055cd13 100644
--- a/dtprobed/dtprobed.c
+++ b/dtprobed/dtprobed.c
@@ -487,7 +487,7 @@ handle_usdt_notes(pid_t pid, uintptr_t addr)
 		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapping (process dead?)\n",
 			 pid);
 		goto out;
-	} else if ((fn = prf->prf_mapname) == NULL) {
+	} else if ((fn = Pmap_mapfile_name(P, mapp)) == NULL) {
 		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapname (process dead?)\n",
 			 pid);
 		goto out;

base-commit: 6e94c7d0a253806f85c39ff5f4e32a800d4cb6b6
-- 
2.51.0.284.g117bcb8de7

Re: [PATCH] dtprobed: use /proc/$pid/map_files, not the filename of the mapping

[Eugene Loh]

I tested on a variety of platforms, and yes this seems to do the job.

The commit message struck me as wordy and hard to follow.  I asked an AI 
bot for its suggestion and (with a slight tweak by me) came up with:

         Instead of using prf->prf_mapname (which resolves to the
         mapped file's target), use Pmap_mapfile_name() to get the
         actual /proc/$pid/map_files/* path.  These special entries
         can be opened even when the apparent symlink looks broken
         or points across filesystem namespaces, ensuring we can
         read the mapping contents reliably.  This matches how DTrace
         handles USDT probe lookup.

         Fixes issues with probes in paths like /home when dtprobed
         is sandboxed by systemd.

which I like better.  (But maybe some other tweak would help better, and 
maybe I've just been staring at this long enough to finally get it.  So, 
I'm not saying this version is the last word on the subject.)

I would like some comment on testing in the commit message.  At this 
point, perhaps it would be a stretch to ask for a test in the test 
suite, given that the issues (systemd, /tmp) are so tied into the test 
suite, but there should be at least a description of how -- and even 
just what! -- to test manually.  How would a reader know what the 
problem is or how to confirm this patch fixes it?

On 12/2/25 18:04, Nick Alcock wrote:
> When hunting down a text mapping, prf->prf_mapname is equivalent to
> looking at the symlink target of the /proc/$pid/map_files/* file, so
> opening that opens (say) /usr/bin/blah. If we use Pmap_mapfile_name()
> instead, we get the name of the actual /proc/$pid/map_files file
> itself. This looks like a symlink, but it's actually magic: it points to
> the target of the mapping even if that target is in a different
> filesystem namespace, and you can dereference and open it to get the
> contents of the mapping even if the symlink is apparently "broken".
> DTrace already uses this elsewhere in USDT probe lookup, so we can
> surely use it here as well.
>
> Fixes e.g. running programs with probes out of /home (which is jailed
> away from dtprobed by dtprobed's systemd service file).
>
> Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> ---
>   dtprobed/dtprobed.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dtprobed/dtprobed.c b/dtprobed/dtprobed.c
> index a808586559d96..9a6928055cd13 100644
> --- a/dtprobed/dtprobed.c
> +++ b/dtprobed/dtprobed.c
> @@ -487,7 +487,7 @@ handle_usdt_notes(pid_t pid, uintptr_t addr)
>   		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapping (process dead?)\n",
>   			 pid);
>   		goto out;
> -	} else if ((fn = prf->prf_mapname) == NULL) {
> +	} else if ((fn = Pmap_mapfile_name(P, mapp)) == NULL) {
>   		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapname (process dead?)\n",
>   			 pid);
>   		goto out;
>
> base-commit: 6e94c7d0a253806f85c39ff5f4e32a800d4cb6b6

Re: [PATCH] dtprobed: use /proc/$pid/map_files, not the filename of the mapping

[Nick Alcock]

On 4 Dec 2025, Eugene Loh told this:

> I tested on a variety of platforms, and yes this seems to do the job.
>
> The commit message struck me as wordy and hard to follow.  I asked an AI bot for its suggestion and (with a slight tweak by me) came
> up with:
>
>         Instead of using prf->prf_mapname (which resolves to the
>         mapped file's target), use Pmap_mapfile_name() to get the
>         actual /proc/$pid/map_files/* path.  These special entries
>         can be opened even when the apparent symlink looks broken
>         or points across filesystem namespaces, ensuring we can
>         read the mapping contents reliably.  This matches how DTrace
>         handles USDT probe lookup.
>
>         Fixes issues with probes in paths like /home when dtprobed
>         is sandboxed by systemd.
>
> which I like better.  (But maybe some other tweak would help better,
> and maybe I've just been staring at this long enough to finally get
> it.  So, I'm not saying this version is the last word on the subject.)

I'm a perfect test reader right now, because I can't remember a thing
about this commit.

The revised message is OK, but not quite right -- it doesn't "match" how
DTrace handles USDT probe lookup, DTrace uses the same mechanism when
doing USDT probe lookup (but that's not actually how USDT probe lookup
is done, it's just one aspect of it).

v2 coming shortly.

> I would like some comment on testing in the commit message.  At this
> point, perhaps it would be a stretch to ask for a test in the test
> suite, given that the issues (systemd, /tmp) are so tied into the test
> suite, but there should be at least a description of how -- and even
> just what! -- to test manually.  How would a reader know what the
> problem is or how to confirm this patch fixes it?

Agreed. I'll soup it up a bit.

-- 
NULL && (void)

[PATCH v2] dtprobed: use /proc/$pid/map_files, not the filename of the mapping

[Nick Alcock]

Instead of using prf->prf_mapname (which resolves to the mapped file's
target), use Pmap_mapfile_name() to get the actual
/proc/$pid/map_files/* path.  These magic symlinks can be opened even
when their corresponding files are deleted or in an inaccessible
filesystem namespace, ensuring we can read the mapping contents
reliably.  DTrace already does this to read mappings during USDT probe
lookup.

Fixes issues with probes in paths like /home when dtprobed
is sandboxed by systemd.

Tested on both systemd and non-systemd (non-jailed) systems, with USDT
programs running out of /tmp, /usr/local and /home.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
---
 dtprobed/dtprobed.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dtprobed/dtprobed.c b/dtprobed/dtprobed.c
index a808586559d96..9a6928055cd13 100644
--- a/dtprobed/dtprobed.c
+++ b/dtprobed/dtprobed.c
@@ -487,7 +487,7 @@ handle_usdt_notes(pid_t pid, uintptr_t addr)
 		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapping (process dead?)\n",
 			 pid);
 		goto out;
-	} else if ((fn = prf->prf_mapname) == NULL) {
+	} else if ((fn = Pmap_mapfile_name(P, mapp)) == NULL) {
 		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapname (process dead?)\n",
 			 pid);
 		goto out;

base-commit: 6e94c7d0a253806f85c39ff5f4e32a800d4cb6b6
-- 
2.52.0.285.g44a719c714.dirty

Re: [DTrace-devel] [PATCH v2] dtprobed: use /proc/$pid/map_files, not the filename of the mapping

[Eugene Loh]

Reviewed-by: Eugene Loh <eugene.loh@oracle.com>

On 1/20/26 11:20, Nick Alcock via DTrace-devel wrote:
> Instead of using prf->prf_mapname (which resolves to the mapped file's
> target), use Pmap_mapfile_name() to get the actual
> /proc/$pid/map_files/* path.  These magic symlinks can be opened even
> when their corresponding files are deleted or in an inaccessible
> filesystem namespace, ensuring we can read the mapping contents
> reliably.  DTrace already does this to read mappings during USDT probe
> lookup.
>
> Fixes issues with probes in paths like /home when dtprobed
> is sandboxed by systemd.
>
> Tested on both systemd and non-systemd (non-jailed) systems, with USDT
> programs running out of /tmp, /usr/local and /home.
>
> Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> ---
>   dtprobed/dtprobed.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dtprobed/dtprobed.c b/dtprobed/dtprobed.c
> index a808586559d96..9a6928055cd13 100644
> --- a/dtprobed/dtprobed.c
> +++ b/dtprobed/dtprobed.c
> @@ -487,7 +487,7 @@ handle_usdt_notes(pid_t pid, uintptr_t addr)
>   		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapping (process dead?)\n",
>   			 pid);
>   		goto out;
> -	} else if ((fn = prf->prf_mapname) == NULL) {
> +	} else if ((fn = Pmap_mapfile_name(P, mapp)) == NULL) {
>   		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapname (process dead?)\n",
>   			 pid);
>   		goto out;
>
> base-commit: 6e94c7d0a253806f85c39ff5f4e32a800d4cb6b6

Re: [DTrace-devel] [PATCH v2] dtprobed: use /proc/$pid/map_files, not the filename of the mapping

[Eugene Loh]

I do not know what went wrong here.  I would have bet big money that I 
tested this, but here is what I find now with this patch:

test/unittest/usdt/tst.enabled.sh: Running timeout --signal=TERM 41 
test/unittest/usdt/tst.enabled.sh /home/.../build/dtrace
FAIL: expected results differ.
400000-401000:main:go

Diff against expected:
--- test/unittest/usdt/tst.enabled.r    2026-02-12 05:31:24.000000000 +0000
+++ /tmp/runtest.6196/test.out  2026-02-12 18:09:58.980466976 +0000
@@ -1,2 +1,2 @@
-test:main:go
+400000-401000:main:go

That is, on several systems I'm getting widespread failure on USDT tests.

On 1/20/26 14:24, Eugene Loh wrote:
> Reviewed-by: Eugene Loh <eugene.loh@oracle.com>
>
> On 1/20/26 11:20, Nick Alcock via DTrace-devel wrote:
>> Instead of using prf->prf_mapname (which resolves to the mapped file's
>> target), use Pmap_mapfile_name() to get the actual
>> /proc/$pid/map_files/* path.  These magic symlinks can be opened even
>> when their corresponding files are deleted or in an inaccessible
>> filesystem namespace, ensuring we can read the mapping contents
>> reliably.  DTrace already does this to read mappings during USDT probe
>> lookup.
>>
>> Fixes issues with probes in paths like /home when dtprobed
>> is sandboxed by systemd.
>>
>> Tested on both systemd and non-systemd (non-jailed) systems, with USDT
>> programs running out of /tmp, /usr/local and /home.
>>
>> Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
>> ---
>>   dtprobed/dtprobed.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/dtprobed/dtprobed.c b/dtprobed/dtprobed.c
>> index a808586559d96..9a6928055cd13 100644
>> --- a/dtprobed/dtprobed.c
>> +++ b/dtprobed/dtprobed.c
>> @@ -487,7 +487,7 @@ handle_usdt_notes(pid_t pid, uintptr_t addr)
>>           fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up 
>> mapping (process dead?)\n",
>>                pid);
>>           goto out;
>> -    } else if ((fn = prf->prf_mapname) == NULL) {
>> +    } else if ((fn = Pmap_mapfile_name(P, mapp)) == NULL) {
>>           fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up 
>> mapname (process dead?)\n",
>>                pid);
>>           goto out;
>>
>> base-commit: 6e94c7d0a253806f85c39ff5f4e32a800d4cb6b6

Re: [DTrace-devel] [PATCH v2] dtprobed: use /proc/$pid/map_files, not the filename of the mapping

[Nick Alcock]

On 12 Feb 2026, Eugene Loh outgrape:

> I do not know what went wrong here.  I would have bet big money that I
> tested this, but here is what I find now with this patch:

So did I!

> test/unittest/usdt/tst.enabled.sh: Running timeout --signal=TERM 41 test/unittest/usdt/tst.enabled.sh /home/.../build/dtrace
> FAIL: expected results differ.
> 400000-401000:main:go
>
> Diff against expected:
> --- test/unittest/usdt/tst.enabled.r    2026-02-12 05:31:24.000000000 +0000
> +++ /tmp/runtest.6196/test.out  2026-02-12 18:09:58.980466976 +0000
> @@ -1,2 +1,2 @@
> -test:main:go
> +400000-401000:main:go

This suggests that symbol lookup is failing, which it shouldn't be,
because that *too* uses /proc/$pid/map_files, or should.

I clearly need to debug this. Got a system on which it goes wrong?

Re: [DTrace-devel] [PATCH v2] dtprobed: use /proc/$pid/map_files, not the filename of the mapping

[Kris Van Hees]

Here is the problem:

        prf = mapp->pr_file;
        if (prf == NULL || (mapp = prf->first_segment) == NULL) { 
                fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapping (process dead?)\n",
                         pid);
                goto out;
        } else if ((fn = Pmap_mapfile_name(P, mapp)) == NULL) {
                fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapname (process dead?)\n",
                         pid);
                goto out;
        }
        mod = strrchr(fn, '/');
        if (mod)
                mod++;
        else
                mod = fn;

Since you changed this to get the mapping filename in map_files, you get a
name that has the address range as its filename, and since that gets used as
the module name, you end up with the wrong module name in the probe spec.

It needs to be the actual filename of the source file that the mapping came
from.

On Thu, Feb 12, 2026 at 06:18:25PM +0000, Nick Alcock wrote:
> On 12 Feb 2026, Eugene Loh outgrape:
> 
> > I do not know what went wrong here.  I would have bet big money that I
> > tested this, but here is what I find now with this patch:
> 
> So did I!
> 
> > test/unittest/usdt/tst.enabled.sh: Running timeout --signal=TERM 41 test/unittest/usdt/tst.enabled.sh /home/.../build/dtrace
> > FAIL: expected results differ.
> > 400000-401000:main:go
> >
> > Diff against expected:
> > --- test/unittest/usdt/tst.enabled.r    2026-02-12 05:31:24.000000000 +0000
> > +++ /tmp/runtest.6196/test.out  2026-02-12 18:09:58.980466976 +0000
> > @@ -1,2 +1,2 @@
> > -test:main:go
> > +400000-401000:main:go
> 
> This suggests that symbol lookup is failing, which it shouldn't be,
> because that *too* uses /proc/$pid/map_files, or should.
> 
> I clearly need to debug this. Got a system on which it goes wrong?

Re: [DTrace-devel] [PATCH v2] dtprobed: use /proc/$pid/map_files, not the filename of the mapping

[Kris Van Hees]

Oh, easy solution.... determine the mod name from prf->prf_mapname like we
did before.  I.e. work with two filenames, one from prf->prf_mapname to get
the module name, and one from Pmap_mapfile_name() to access the mapping data.

On Thu, Feb 12, 2026 at 01:28:08PM -0500, Kris Van Hees via DTrace-devel wrote:
> Here is the problem:
> 
>         prf = mapp->pr_file;
>         if (prf == NULL || (mapp = prf->first_segment) == NULL) { 
>                 fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapping (process dead?)\n",
>                          pid);
>                 goto out;
>         } else if ((fn = Pmap_mapfile_name(P, mapp)) == NULL) {
>                 fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapname (process dead?)\n",
>                          pid);
>                 goto out;
>         }
>         mod = strrchr(fn, '/');
>         if (mod)
>                 mod++;
>         else
>                 mod = fn;
> 
> Since you changed this to get the mapping filename in map_files, you get a
> name that has the address range as its filename, and since that gets used as
> the module name, you end up with the wrong module name in the probe spec.
> 
> It needs to be the actual filename of the source file that the mapping came
> from.
> 
> On Thu, Feb 12, 2026 at 06:18:25PM +0000, Nick Alcock wrote:
> > On 12 Feb 2026, Eugene Loh outgrape:
> > 
> > > I do not know what went wrong here.  I would have bet big money that I
> > > tested this, but here is what I find now with this patch:
> > 
> > So did I!
> > 
> > > test/unittest/usdt/tst.enabled.sh: Running timeout --signal=TERM 41 test/unittest/usdt/tst.enabled.sh /home/.../build/dtrace
> > > FAIL: expected results differ.
> > > 400000-401000:main:go
> > >
> > > Diff against expected:
> > > --- test/unittest/usdt/tst.enabled.r    2026-02-12 05:31:24.000000000 +0000
> > > +++ /tmp/runtest.6196/test.out  2026-02-12 18:09:58.980466976 +0000
> > > @@ -1,2 +1,2 @@
> > > -test:main:go
> > > +400000-401000:main:go
> > 
> > This suggests that symbol lookup is failing, which it shouldn't be,
> > because that *too* uses /proc/$pid/map_files, or should.
> > 
> > I clearly need to debug this. Got a system on which it goes wrong?
> 
> _______________________________________________
> DTrace-devel mailing list
> DTrace-devel@oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/dtrace-devel

Re: [DTrace-devel] [PATCH v2] dtprobed: use /proc/$pid/map_files, not the filename of the mapping

[Kris Van Hees]

I believe the following on top of the original patch should resolve this:

diff --git a/dtprobed/dtprobed.c b/dtprobed/dtprobed.c
index 9a692805..34349deb 100644
--- a/dtprobed/dtprobed.c
+++ b/dtprobed/dtprobed.c
@@ -487,16 +487,17 @@ handle_usdt_notes(pid_t pid, uintptr_t addr)
 		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapping (process dead?)\n",
 			 pid);
 		goto out;
-	} else if ((fn = Pmap_mapfile_name(P, mapp)) == NULL) {
+	} else if (prf->prf_mapname == NULL ||
+		   (fn = Pmap_mapfile_name(P, mapp)) == NULL) {
 		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapname (process dead?)\n",
 			 pid);
 		goto out;
 	}
-	mod = strrchr(fn, '/');
+	mod = strrchr(prf->prf_mapname, '/');
 	if (mod)
 		mod++;
 	else
-		mod = fn;


On Thu, Feb 12, 2026 at 01:37:06PM -0500, Kris Van Hees wrote:
> Oh, easy solution.... determine the mod name from prf->prf_mapname like we
> did before.  I.e. work with two filenames, one from prf->prf_mapname to get
> the module name, and one from Pmap_mapfile_name() to access the mapping data.
> 
> On Thu, Feb 12, 2026 at 01:28:08PM -0500, Kris Van Hees via DTrace-devel wrote:
> > Here is the problem:
> > 
> >         prf = mapp->pr_file;
> >         if (prf == NULL || (mapp = prf->first_segment) == NULL) { 
> >                 fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapping (process dead?)\n",
> >                          pid);
> >                 goto out;
> >         } else if ((fn = Pmap_mapfile_name(P, mapp)) == NULL) {
> >                 fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapname (process dead?)\n",
> >                          pid);
> >                 goto out;
> >         }
> >         mod = strrchr(fn, '/');
> >         if (mod)
> >                 mod++;
> >         else
> >                 mod = fn;
> > 
> > Since you changed this to get the mapping filename in map_files, you get a
> > name that has the address range as its filename, and since that gets used as
> > the module name, you end up with the wrong module name in the probe spec.
> > 
> > It needs to be the actual filename of the source file that the mapping came
> > from.
> > 
> > On Thu, Feb 12, 2026 at 06:18:25PM +0000, Nick Alcock wrote:
> > > On 12 Feb 2026, Eugene Loh outgrape:
> > > 
> > > > I do not know what went wrong here.  I would have bet big money that I
> > > > tested this, but here is what I find now with this patch:
> > > 
> > > So did I!
> > > 
> > > > test/unittest/usdt/tst.enabled.sh: Running timeout --signal=TERM 41 test/unittest/usdt/tst.enabled.sh /home/.../build/dtrace
> > > > FAIL: expected results differ.
> > > > 400000-401000:main:go
> > > >
> > > > Diff against expected:
> > > > --- test/unittest/usdt/tst.enabled.r    2026-02-12 05:31:24.000000000 +0000
> > > > +++ /tmp/runtest.6196/test.out  2026-02-12 18:09:58.980466976 +0000
> > > > @@ -1,2 +1,2 @@
> > > > -test:main:go
> > > > +400000-401000:main:go
> > > 
> > > This suggests that symbol lookup is failing, which it shouldn't be,
> > > because that *too* uses /proc/$pid/map_files, or should.
> > > 
> > > I clearly need to debug this. Got a system on which it goes wrong?
> > 
> > _______________________________________________
> > DTrace-devel mailing list
> > DTrace-devel@oss.oracle.com
> > https://oss.oracle.com/mailman/listinfo/dtrace-devel

Re: [DTrace-devel] [PATCH v2] dtprobed: use /proc/$pid/map_files, not the filename of the mapping

[Eugene Loh]

On 2/12/26 13:43, Kris Van Hees wrote:

> I believe the following on top of the original patch should resolve this:
>
> diff --git a/dtprobed/dtprobed.c b/dtprobed/dtprobed.c
> index 9a692805..34349deb 100644
> --- a/dtprobed/dtprobed.c
> +++ b/dtprobed/dtprobed.c
> @@ -487,16 +487,17 @@ handle_usdt_notes(pid_t pid, uintptr_t addr)
>   		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapping (process dead?)\n",
>   			 pid);
>   		goto out;
> -	} else if ((fn = Pmap_mapfile_name(P, mapp)) == NULL) {
> +	} else if (prf->prf_mapname == NULL ||
> +		   (fn = Pmap_mapfile_name(P, mapp)) == NULL) {
>   		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapname (process dead?)\n",
>   			 pid);
>   		goto out;
>   	}
> -	mod = strrchr(fn, '/');
> +	mod = strrchr(prf->prf_mapname, '/');
>   	if (mod)
>   		mod++;
>   	else
> -		mod = fn;

Is that a '-' on the last line?

> On Thu, Feb 12, 2026 at 01:37:06PM -0500, Kris Van Hees wrote:
>> Oh, easy solution.... determine the mod name from prf->prf_mapname like we
>> did before.  I.e. work with two filenames, one from prf->prf_mapname to get
>> the module name, and one from Pmap_mapfile_name() to access the mapping data.
>>
>> On Thu, Feb 12, 2026 at 01:28:08PM -0500, Kris Van Hees via DTrace-devel wrote:
>>> Here is the problem:
>>>
>>>          prf = mapp->pr_file;
>>>          if (prf == NULL || (mapp = prf->first_segment) == NULL) {
>>>                  fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapping (process dead?)\n",
>>>                           pid);
>>>                  goto out;
>>>          } else if ((fn = Pmap_mapfile_name(P, mapp)) == NULL) {
>>>                  fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapname (process dead?)\n",
>>>                           pid);
>>>                  goto out;
>>>          }
>>>          mod = strrchr(fn, '/');
>>>          if (mod)
>>>                  mod++;
>>>          else
>>>                  mod = fn;
>>>
>>> Since you changed this to get the mapping filename in map_files, you get a
>>> name that has the address range as its filename, and since that gets used as
>>> the module name, you end up with the wrong module name in the probe spec.
>>>
>>> It needs to be the actual filename of the source file that the mapping came
>>> from.
>>>
>>> On Thu, Feb 12, 2026 at 06:18:25PM +0000, Nick Alcock wrote:
>>>> On 12 Feb 2026, Eugene Loh outgrape:
>>>>
>>>>> I do not know what went wrong here.  I would have bet big money that I
>>>>> tested this, but here is what I find now with this patch:
>>>> So did I!
>>>>
>>>>> test/unittest/usdt/tst.enabled.sh: Running timeout --signal=TERM 41 test/unittest/usdt/tst.enabled.sh /home/.../build/dtrace
>>>>> FAIL: expected results differ.
>>>>> 400000-401000:main:go
>>>>>
>>>>> Diff against expected:
>>>>> --- test/unittest/usdt/tst.enabled.r    2026-02-12 05:31:24.000000000 +0000
>>>>> +++ /tmp/runtest.6196/test.out  2026-02-12 18:09:58.980466976 +0000
>>>>> @@ -1,2 +1,2 @@
>>>>> -test:main:go
>>>>> +400000-401000:main:go
>>>> This suggests that symbol lookup is failing, which it shouldn't be,
>>>> because that *too* uses /proc/$pid/map_files, or should.
>>>>
>>>> I clearly need to debug this. Got a system on which it goes wrong?
>>> _______________________________________________
>>> DTrace-devel mailing list
>>> DTrace-devel@oss.oracle.com
>>> https://oss.oracle.com/mailman/listinfo/dtrace-devel

Re: [DTrace-devel] [PATCH v2] dtprobed: use /proc/$pid/map_files, not the filename of the mapping

[Kris Van Hees]

On Thu, Feb 12, 2026 at 01:49:54PM -0500, Eugene Loh wrote:
> On 2/12/26 13:43, Kris Van Hees wrote:
> 
> > I believe the following on top of the original patch should resolve this:
> > 
> > diff --git a/dtprobed/dtprobed.c b/dtprobed/dtprobed.c
> > index 9a692805..34349deb 100644
> > --- a/dtprobed/dtprobed.c
> > +++ b/dtprobed/dtprobed.c
> > @@ -487,16 +487,17 @@ handle_usdt_notes(pid_t pid, uintptr_t addr)
> >   		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapping (process dead?)\n",
> >   			 pid);
> >   		goto out;
> > -	} else if ((fn = Pmap_mapfile_name(P, mapp)) == NULL) {
> > +	} else if (prf->prf_mapname == NULL ||
> > +		   (fn = Pmap_mapfile_name(P, mapp)) == NULL) {
> >   		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapname (process dead?)\n",
> >   			 pid);
> >   		goto out;
> >   	}
> > -	mod = strrchr(fn, '/');
> > +	mod = strrchr(prf->prf_mapname, '/');
> >   	if (mod)
> >   		mod++;
> >   	else
> > -		mod = fn;
> 
> Is that a '-' on the last line?

Yes, but it is missing the last line (sorry about that):

+		mod = prf->prf_mapname;

> > On Thu, Feb 12, 2026 at 01:37:06PM -0500, Kris Van Hees wrote:
> > > Oh, easy solution.... determine the mod name from prf->prf_mapname like we
> > > did before.  I.e. work with two filenames, one from prf->prf_mapname to get
> > > the module name, and one from Pmap_mapfile_name() to access the mapping data.
> > > 
> > > On Thu, Feb 12, 2026 at 01:28:08PM -0500, Kris Van Hees via DTrace-devel wrote:
> > > > Here is the problem:
> > > > 
> > > >          prf = mapp->pr_file;
> > > >          if (prf == NULL || (mapp = prf->first_segment) == NULL) {
> > > >                  fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapping (process dead?)\n",
> > > >                           pid);
> > > >                  goto out;
> > > >          } else if ((fn = Pmap_mapfile_name(P, mapp)) == NULL) {
> > > >                  fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapname (process dead?)\n",
> > > >                           pid);
> > > >                  goto out;
> > > >          }
> > > >          mod = strrchr(fn, '/');
> > > >          if (mod)
> > > >                  mod++;
> > > >          else
> > > >                  mod = fn;
> > > > 
> > > > Since you changed this to get the mapping filename in map_files, you get a
> > > > name that has the address range as its filename, and since that gets used as
> > > > the module name, you end up with the wrong module name in the probe spec.
> > > > 
> > > > It needs to be the actual filename of the source file that the mapping came
> > > > from.
> > > > 
> > > > On Thu, Feb 12, 2026 at 06:18:25PM +0000, Nick Alcock wrote:
> > > > > On 12 Feb 2026, Eugene Loh outgrape:
> > > > > 
> > > > > > I do not know what went wrong here.  I would have bet big money that I
> > > > > > tested this, but here is what I find now with this patch:
> > > > > So did I!
> > > > > 
> > > > > > test/unittest/usdt/tst.enabled.sh: Running timeout --signal=TERM 41 test/unittest/usdt/tst.enabled.sh /home/.../build/dtrace
> > > > > > FAIL: expected results differ.
> > > > > > 400000-401000:main:go
> > > > > > 
> > > > > > Diff against expected:
> > > > > > --- test/unittest/usdt/tst.enabled.r    2026-02-12 05:31:24.000000000 +0000
> > > > > > +++ /tmp/runtest.6196/test.out  2026-02-12 18:09:58.980466976 +0000
> > > > > > @@ -1,2 +1,2 @@
> > > > > > -test:main:go
> > > > > > +400000-401000:main:go
> > > > > This suggests that symbol lookup is failing, which it shouldn't be,
> > > > > because that *too* uses /proc/$pid/map_files, or should.
> > > > > 
> > > > > I clearly need to debug this. Got a system on which it goes wrong?
> > > > _______________________________________________
> > > > DTrace-devel mailing list
> > > > DTrace-devel@oss.oracle.com
> > > > https://oss.oracle.com/mailman/listinfo/dtrace-devel

Re: [DTrace-devel] [PATCH v2] dtprobed: use /proc/$pid/map_files, not the filename of the mapping

[Nick Alcock]

On 12 Feb 2026, Kris Van Hees outgrape:

> On Thu, Feb 12, 2026 at 01:49:54PM -0500, Eugene Loh wrote:
>> On 2/12/26 13:43, Kris Van Hees wrote:
>> 
>> > I believe the following on top of the original patch should resolve this:
>> > 
>> > diff --git a/dtprobed/dtprobed.c b/dtprobed/dtprobed.c
>> > index 9a692805..34349deb 100644
>> > --- a/dtprobed/dtprobed.c
>> > +++ b/dtprobed/dtprobed.c
>> > @@ -487,16 +487,17 @@ handle_usdt_notes(pid_t pid, uintptr_t addr)
>> >   		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapping (process dead?)\n",
>> >   			 pid);
>> >   		goto out;
>> > -	} else if ((fn = Pmap_mapfile_name(P, mapp)) == NULL) {
>> > +	} else if (prf->prf_mapname == NULL ||
>> > +		   (fn = Pmap_mapfile_name(P, mapp)) == NULL) {
>> >   		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapname (process dead?)\n",
>> >   			 pid);
>> >   		goto out;
>> >   	}
>> > -	mod = strrchr(fn, '/');
>> > +	mod = strrchr(prf->prf_mapname, '/');
>> >   	if (mod)
>> >   		mod++;
>> >   	else
>> > -		mod = fn;
>> 
>> Is that a '-' on the last line?
>
> Yes, but it is missing the last line (sorry about that):
>
> +		mod = prf->prf_mapname;

Given that...

Reviewed-by: Nick Alcock <nick.alcock@oracle.com>

I have *no idea* how this worked when I tested it. The whole testsuite
passed...