I compiled a Fortran90 program with pgf90, and the program seems to run as expected. When I run pgdbg, it reports that the executable was loaded; but when I type “run” it returns “ERROR: CANNOT LOAD”. How can I figure out what’s going on please?
Also, it’s a large complicated program and pgdbg seems to re-build laboriously the same dSYM sub-directory every time. How can I re-use that?
Ps., after posting above, I find I get the same problem even with a very short single F90 source, compiling just with “pgf90 -g”.
I am running a Mac OS X Intel Core 2 Duo. Could there be a 32- vs 64-bit issue?
Aime
Sorry you are having troubles with PGDBG. There are a few things you could do to help diagnose the problem.
The first thing to check on Mac OS X is that the debugger will run with group “procmod” privileges. This is supposed to be handled during installation, but perhaps in your case it wasn’t. That can be accomplished in two ways:
(1) you are a member of group procmod
(2) the permissions on the executable named “pgdebug” should be “setgid procmod”
In addition, the debugger executable must be installed on a local drive.
This is all due to Mac OS X security requirements.
To see if you are a member of group procmod, run
$ id
and look to see if procmod shows up in the list.
To see if the debugger (an executable named “pgdebug”) has “setgid procmod” permissions, you can run the following commands:
$ which pgdebug
/usr/pgi/osx86-64/10.1/bin/pgdebug
$ ls -l `which pgdebug`
-rwxrwsr-x 1 myname procmod 12820680 Jan 6 16:00 /usr/pgi/osx86-64/10.1/bin/pgdebug*
Note that it is owned by group procmod and the setgid bit is set (that is the ‘s’ in rwxrwsr-x).
To see if the debugger is on a local drive, use the ‘df’ command on the directory where the “pgdebug” executable is located:
$df /usr/pgi/osx86-64/10.1/bin
If the Filesystem in the output looks something like /dev/disk0s2, it is a local filesystem and should be OK. If it looks more like foo.bar.com:/vol/vol5/dir1, then it is a network drive, and that is a problem.
Other things of interest: what version of Mac OS X are you running (10.4/Tiger, 10.5/Leopard, 10.6/Snow Leopard)? Select the About box under the Apple menu to find this information.
As to your other questions:
(1) can you re-use the dSYM directory - unfortunately, at this time pgdbg regenerates it for every debug session.
(2) is it a 64-bit vs 32-bit issue - it’s possible but seems unlikely given the symptoms you describe.
Let us know what you find out. We want to get you up and running!
thanks
–Don
Thanks for the fast reply!
I belong only to the group “users”.
The setgid bit is set exactly as you describe.
The debugger is local, exactly as you describe.
Other info:
System Version: Mac OS X 10.5.8 (9L31a)
Kernel Version: Darwin 9.8.0
Details:
~/tests>id
uid=5611(fournier) gid=15(users) groups=15(users)
~/tests>ls -l `which pgdebug`
-rwxrwsr-x 1 root procmod 8827988 Feb 11 2009 /usr/local/pgi/bin/pgdebug*
~/tests>which pgdebug
/usr/local/pgi/bin/pgdebug
~/tests>df /usr/local/pgi/bin/
Filesystem 512-blocks Used Available Capacity Mounted on
/dev/disk0s2 105829464 76330776 28986688 73% /
I reproduce the problem with this source:
PROGRAM test
IMPLICIT NONE
PRINT*,"Hello world"
END PROGRAM test
Aime,
A few more questions:
(1) what version of PGI software are you running?
$ pgf90 -V
(2) what is the command line you are using to invoke pgdbg?
(3) is the CANNOT LOAD error the only one that you see? can you copy/paste the output of your debug session and post it?
(4) you are running 64-bit code on a 64-bit operating system, correct?
thanks
–Don
Don, thanks. I need to watch the baby Tuesday and won’t be able to mount the disk again where pgf90 etc. are until Wednesday. In GUI I recall only that error message, but I can also paste my previous text session:
>pgdbg -text ./a.out
PGDBG 8.0-4 x86 (Workstation, 16 Process)
Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved.
Copyright 2000-2008, STMicroelectronics, Inc. All Rights Reserved.
Loaded: /Volumes/Users/fournier/tests/a.out
pgdbg> run
pserv_init: task_for_pid failed: (os/kern) failure
init_exception_handling: task_get_exception_ports excpt_port fails (ipc/send) invalid destination port
- recv: message receive: Undefined error: 0
fetch_request : broken pipe or eof: Undefined error: 0
- recv: message receive: Undefined error: 0
fetch_request : broken pipe or eof: Undefined error: 0
- send: message send: Broken pipe
pserv_write_msg : write failed: Broken pipe
- send: message send: Broken pipe
pserv_write_msg : write failed: Broken pipe
ERROR: CANNOT LOAD /Volumes/Users/fournier/tests/a.out.
Aime,
This message:
pserv_init: task_for_pid failed: (os/kern) failure
is a clear indication that the problem is related to insufficient privileges with respect to the procmod group.
From your previous postings, I get the impression that your installation may have been customized a bit. If so, that may be affecting this.
The pgdbg driver runs the version of pgdebug that is in the directory where pgdbg and pgdbg1 are located. So even if you have a version of pgdebug on your path in front of pgdbg, if the version of pgdebug in the same directory as pgdbg doesn’t have procmod privileges, you will get an error.
For example:
/usr/local/pgi/bin/pgdebug rwxrwsr-x root procmod
/opt/pgi/osx86/8.0-4/bin/pgdebug rwxrwxr-x root system
/opt/pgi/osx86/8.0-4/bin/pgdbg
/opt/pgi/osx86/8.0-4/bin/pgdbg1
In this scenario, even if /usr/local/pgi/bin is at the front of your PATH, pgdbg will run the copy of pgdebug in /opt/pgi and it will fail due to the procmod issue.
That said, I haven’t been able to reproduce the behavior you are seeing. My copy of the 8.0-4 debugger prints a more informative error in this situation, complaining about the lack of procmod privilege.
At this point I’d suggest the following:
–Don
Are some CRs mixed up in the 2nd Code part of your message? Here’s what I get:
>ls -l /usr/local/pgi/bin/pgd*b*
-rwxrwxr-x 1 root admin 9990 Feb 11 2009 /usr/local/pgi/bin/pgdbg*
-rwxrwsr-x 1 root kmem 23376 Feb 11 2009 /usr/local/pgi/bin/pgdbg1*
-rwxrwsr-x 1 root procmod 8827988 Feb 11 2009 /usr/local/pgi/bin/pgdebug*
Does that need fixing?
Aime,
Apologies for the delay in answering.
I experimented with making my copy of pgdbg1 setgid kmem and it didn’t seem to have any negative effect. However, there is no reason for it to run setgid kmem, so if I were you I would change it back to group admin with no setgid.
To cover all our bases, we should look at the permissions you have on another executable named pgserv. This is essentially the back-end of the parallel debugger. If its permissions have been modified that could create this problem. It is in the same bin directory with the rest of them.
Ideally, in 8.0-4 all the executables in the bin directory should have “normal” permissions/privileges except for pgdebug, which should have setgid procmod.
Please let me know what you find out.
–Don
Here are “all the executables in the bin directory”:
>ls -l /usr/local/pgi/bin/ | egrep '\*$'
-rwxrwxr-x 1 root admin 1489688 Feb 11 2009 Jpgprof.jar*
-rwxrwxr-x 1 root admin 500623 Feb 11 2009 jh.jar*
-rwxrwxr-x 1 root admin 358081 Feb 11 2009 jpgdbg.jar*
-rwxrwxr-x 1 root admin 9797 Mar 11 2009 makelocalrc*
-rwxr-xr-x 1 root admin 9791 Mar 11 2009 makelocalrc.org*
-rwxr-xr-x 1 root admin 69475 Feb 11 2009 optopgprof*
-rwxrwxr-x 1 root admin 427 Feb 11 2009 osxtools86rc*
-rwxrwxr-x 1 root admin 78696 Feb 11 2009 pgappend*
-rwxrwxr-x 1 root admin 49304 Feb 11 2009 pgar*
-rwxrwxr-x 1 root admin 192484 Feb 11 2009 pgcc*
-rwxrwxr-x 1 root admin 1411708 Feb 11 2009 pgcheckout*
-rwxrwxr-x 1 root admin 196744 Feb 11 2009 pgcpp*
-rwxrwxr-x 1 root admin 25820 Feb 11 2009 pgcpuid*
-rwxrwxr-x 1 root admin 9990 Feb 11 2009 pgdbg*
-rwxrwsr-x 1 root kmem 23376 Feb 11 2009 pgdbg1*
-rwxrwsr-x 1 root procmod 8827988 Feb 11 2009 pgdebug*
-rwxrwxr-x 1 root admin 35980 Feb 11 2009 pgdecode*
-rwxrwxr-x 1 root admin 60924 Feb 11 2009 pgextract*
-rwxrwxr-x 1 root admin 192484 Feb 11 2009 pgf77*
-rwxrwxr-x 1 root admin 192484 Feb 11 2009 pgf90*
-rwxrwxr-x 1 root admin 192484 Feb 11 2009 pgf95*
-rwxrwxr-x 1 root admin 192484 Feb 11 2009 pghpf*
-rwxrwxr-x 1 root admin 381380 Feb 11 2009 pgipa*
-rwxr-xr-x 1 root admin 13788 Feb 11 2009 pgoprun*
-rwxrwxr-x 1 root admin 1501660 Feb 11 2009 pgprepro*
-rwxrwxr-x 1 root admin 197160 Feb 11 2009 pgprof*
-rwxrwxr-x 1 root admin 8507 Feb 11 2009 pgprofrc*
-rwxrwsr-x 1 root kmem 84212 Feb 11 2009 pgserv*
-rwxrwxr-x 1 root admin 638372 Feb 11 2009 pgsmart*
-rwxrwxr-x 1 root admin 47480 Feb 11 2009 pgunzip*
-rwxrwxr-x 1 root admin 48492 Feb 11 2009 pgzip*
Is there a problem with that?
Aime,
Yes, the executable file “pgserv” should not have the set-group-id bit set, nor should it be in group “kmem”. That is overriding the “procmod” group privileges that pgserv inherits from pgdebug when pgdebug executes it.
I recommend the following commands (it will require a privileged user to make these changes successfully):
$cd /usr/local/pgi/bin
$ chgrp admin pgdbg1 pgserv
$ chmod 775 pgdbg1 pgserv
Let me know how it goes.
–Don
Don,
That did the trick. Thanks!
Aimé
I have a similar issue as the person in this posting, except the solution didn’t work for me.
Error:
matt@pontus:run.14.all_tlm-nox_emi$ pgdebug ctm_mod.Abs
PGDBG 10.9-0 x86-64 (Workstation, 8 Process)
Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved.
Copyright 2000-2010, STMicroelectronics, Inc. All Rights Reserved.
Loaded: /Users/matt/aurams/trunk/versions/beta/runs/run.14.all_tlm-nox_emi/ctm_mod.Abs
pgdbg> run
pserv_init: task_for_pid failed: (os/kern) failure
- recv: message receive: Undefined error: 0
fetch_request : broken pipe or eof: Undefined error: 0
- recv: message receive: Undefined error: 0
fetch_request : broken pipe or eof: Undefined error: 0
- recv: message receive: Undefined error: 0
fetch_request : broken pipe or eof: Undefined error: 0
- recv: message receive: Undefined error: 0
fetch_request : broken pipe or eof: Undefined error: 0
ERROR: CANNOT LOAD /Users/matt/aurams/trunk/versions/beta/runs/run.14.all_tlm-nox_emi/ctm_mod.Abs.
PGI directory:
cd /opt/pgi/osx86-64/10.9/bin
ls
...
-rwxrwxr-x 1 root admin 91K 9 Sep 2010 pgserv
-rwxrwxr-x 1 root admin 14M 9 Sep 2010 pgdebug
-rwxrwxr-x 1 root admin 252K 9 Sep 2010 pgdbg
...
I also tried adding my self to the procmod group, I had those files above in the procmod group, I tried them with the set GID bit, etc… No luck so far.
I’m using OS X Lion (1.7.3), 86x64 architecture, PGI 10.9
Help?
The task_for_pid error is always a result of the procmod permission issue. So I’m guessing that after fixing the permissions, you started seeing some other errors.
It looks like you are using PGI 10.9.
Lion has some new security features that affect debugging. To use PGDBG on Lion, you will need release 12.1. Also, in 12.1 on Lion, dynamic library debugging (e.g. .dylib files) is disabled. We are working with Apple to resolve that issue.
–Don
Oh… Though I do have a current PGI subscription on one of our Linux boxes, the subscription on this OS X machine is expired.
So… Basically I won’t be able to debug my code with the PGI debugger we bought on OS X Lion without re-buying a license to upgrade it?
Can PGI code be debugged with gdb? (I know this is a general question, but I’ve never actually known the answer.)
Hi khea_actual1,
So… Basically I won’t be able to debug my code with the PGI debugger we bought on OS X Lion without re-buying a license to upgrade it?
Contact PGI Sales (sales@pgroup.com) to get a quote. Typically, you only need to pay the cost to bring your subscription current. Note that Lion was not officially supported till the 2011 release.
Can PGI code be debugged with gdb?
Yes, but gdb doesn’t know Fortran so it may have trouble listing some symbols. It’s also my understanding that you need to have root privileges in order to run gdb on Lion.
Hi,
Since that last posting, I have updated my subscription and have upgraded to 12.9, but have also upgraded the OS to Mountain Lion.
I still see the same error when I try to debug,
matt@pontus:run.generic$ pgdebug ctm_mod.Abs
PGDBG 12.9-0 x86-64 (Workstation, 16 Process)
Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved.
Copyright 2000-2012, STMicroelectronics, Inc. All Rights Reserved.
Loaded: /Users/matt/aurams/trunk/versions/kappa12/runs/run.generic/ctm_mod.Abs
pgdbg> run
pserv_init: task_for_pid failed: (os/kern) failure
- recv: message receive: Undefined error: 0
- recv: message receive: Undefined error: 0
- recv: message receive: Connection reset by peer
- send: message send: Broken pipe
ERROR: CANNOT LOAD /Users/matt/aurams/trunk/versions/kappa12/runs/run.generic/ctm_mod.Abs
File permissions,
-rwxrwsr-x 1 root procmod 22M 20 Sep 16:48 pgdebug
-rwxrwsr-x 1 root procmod 133K 20 Sep 16:48 pgserv
Is there any way I can run the debugger on Mountain Lion?
The “task_for_pid” failure means that it is a problem with your privileges configuration.
It looks like your permissions are correct. Did you install the debugger on a local drive? Are you a member of the “procmod” group?
Hi Mat, sorry for my late reply.
The debugger is installed on a local drive, and I am in that group:
matt@pontus:run.generic$ dscl . -read /Groups/procmod GroupMembership
GroupMembership: root matt
After adding my self to it, I logged out and logged in, and still got the same error:
matt@pontus:run.generic$ pgdebug ctm_pre.Abs
PGDBG 12.9-0 x86-64 (Workstation, 16 Process)
Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved.
Copyright 2000-2012, STMicroelectronics, Inc. All Rights Reserved.
Loaded: /Users/matt/aurams/trunk/versions/kappa13/runs/run.generic/ctm_pre.Abs
pgdbg> run
pserv_init: task_for_pid failed: (os/kern) failure
- recv: message receive: Undefined error: 0
- recv: message receive: Undefined error: 0
- recv: message receive: Undefined error: 0
- send: message send: Broken pipe
ERROR: CANNOT LOAD /Users/matt/aurams/trunk/versions/kappa13/runs/run.generic/ctm_pre.Abs.
So the debugger just doesn’t work on Mountain Lion? :(