The debugger plugin closes the debugging section if you try to do a [Step in] to any **glibc** sys function.
**GDB** throws an exception with "No such file or directory." and the debugging section is then stopped or closed.
We need a way to pass to the debugger plugin where the source code of **glibc** is, so no exception is raised.
**Example:**
```
GNU gdb (Ubuntu 8.1.1-0ubuntu1) 8.1.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./minicom...done.
(gdb) b 77
Breakpoint 1 at 0x5365: file minicom.c, line 77.
(gdb) s
The program is not being run.
(gdb) run
Starting program: /apps/minicom-2.7.1/debian/minicom/usr/bin/minicom -D /dev/ttyUSB1
Lockfile is stale. Overriding it..
Breakpoint 1, port_init () at minicom.c:77
77 m_setparms(portfd, P_BAUDRATE, P_PARITY, P_BITS, P_STOPB,
(gdb) s
78 P_HASRTS[0] == 'Y', P_HASXON[0] == 'Y');
(gdb) s
77 m_setparms(portfd, P_BAUDRATE, P_PARITY, P_BITS, P_STOPB,
(gdb) s
m_setparms (fd=3, baudr=0x5555557866e0 <mpars+4032> "1500000",
par=0x555555786800 <mpars+4320> "N", bits=0x555555786770 <mpars+4176> "8",
stopb=0x555555786890 <mpars+4464> "1", hwf=1, swf=0) at sysdep1.c:396
396 {
(gdb) s
397 int spd = -1;
(gdb) s
399 int bit = bits[0];
(gdb) s
408 if (portfd_is_socket)
(gdb) s
413 tcgetattr(fd, &tty);
(gdb) s
__GI___tcgetattr (fd=3, termios_p=0x7fffffffde30)
at ../sysdeps/unix/sysv/linux/tcgetattr.c:34
34 ../sysdeps/unix/sysv/linux/tcgetattr.c: No such file or directory.
(gdb) s
38 in ../sysdeps/unix/sysv/linux/tcgetattr.c
(gdb) s
34 in ../sysdeps/unix/sysv/linux/tcgetattr.c
(gdb) s
38 in ../sysdeps/unix/sysv/linux/tcgetattr.c
(gdb) s
40 in ../sysdeps/unix/sysv/linux/tcgetattr.c
(gdb) s
46 in ../sysdeps/unix/sysv/linux/tcgetattr.c
(gdb) s
63 in ../sysdeps/unix/sysv/linux/tcgetattr.c
(gdb) s
42 in ../sysdeps/unix/sysv/linux/tcgetattr.c
(gdb) s
63 in ../sysdeps/unix/sysv/linux/tcgetattr.c
(gdb) s
42 in ../sysdeps/unix/sysv/linux/tcgetattr.c
(gdb) n
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x1ec4635941ad2a3e
__longjmp () at ../sysdeps/x86_64/__longjmp.S:45
45 ../sysdeps/x86_64/__longjmp.S: No such file or directory.
(gdb)
```
With **GDB** you can pass a parameter informing where to search for glibc source code, here is how:
_-d "directory to search"_
**sudo gdb -d /apps/libc6/glibc-2.27/stamp-dir --args ./minicom -D /dev/ttyUSB1**
```
GNU gdb (Ubuntu 8.1.1-0ubuntu1) 8.1.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./minicom...done.
(gdb) show directories
Source directories searched: /apps/libc6/glibc-2.27/stamp-dir:$cdir:$cwd
(gdb) b 77
Breakpoint 1 at 0x5365: file minicom.c, line 77.
(gdb) run
Starting program: /apps/minicom-2.7.1/debian/minicom/usr/bin/minicom -D /dev/ttyUSB1
Lockfile is stale. Overriding it..
Breakpoint 1, port_init () at minicom.c:77
77 m_setparms(portfd, P_BAUDRATE, P_PARITY, P_BITS, P_STOPB,
(gdb) s
78 P_HASRTS[0] == 'Y', P_HASXON[0] == 'Y');
(gdb) s
77 m_setparms(portfd, P_BAUDRATE, P_PARITY, P_BITS, P_STOPB,
(gdb) s
m_setparms (fd=3, baudr=0x5555557866e0 <mpars+4032> "1500000",
par=0x555555786800 <mpars+4320> "N", bits=0x555555786770 <mpars+4176> "8",
stopb=0x555555786890 <mpars+4464> "1", hwf=1, swf=0) at sysdep1.c:396
396 {
(gdb) s
397 int spd = -1;
(gdb) s
399 int bit = bits[0];
(gdb) s
408 if (portfd_is_socket)
(gdb) s
413 tcgetattr(fd, &tty);
(gdb) s
__GI___tcgetattr (fd=3, termios_p=0x7fffffffde10)
at ../sysdeps/unix/sysv/linux/tcgetattr.c:34
34 {
(gdb) s
38 retval = INLINE_SYSCALL (ioctl, 3, fd, TCGETS, &k_termios);
(gdb) s
34 {
(gdb) info source
Current source file is ../sysdeps/unix/sysv/linux/tcgetattr.c
Compilation directory is /build/glibc-CVJwZb/glibc-2.27/termios
Located in /apps/libc6/glibc-2.27/sysdeps/unix/sysv/linux/tcgetattr.c
Contains 80 lines.
Source language is c.
Producer is GNU C11 7.5.0 -mtune=generic -march=x86-64 -g -O2 -O3 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math -fstack-protector-strong -fPIC -ftls-model=initial-exec -fstack-protector-strong.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.
(gdb)
```
I think there must be a way to tell **the debugger plugin** to pass the directory to search, so the debugging section is not closed.
I am still searching if is not possible to export a variable previous to debug with Geany to bypass the error.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1179
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/issues/1179(a)github.com>
Dear all,
I am very thankful to the debugger plugin team. It is a very good tool to my work.
I would like to ask some "how to" here. Maybe some of them can be considered into wishlist.
1. How to show variables' address?
In F90, we have LOC(x) to show its address in memery. Can I use it in the "watching window" as well?
2.how to access some variables that are located under module?
In intel f90+VS in Windows10, we have "mod::" method in debugger to enable this. Can we have the similar functions in geany?
3. ... (Maybe we can add more "enhancement" under this box?:D)
Thanks.
Shuo
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/583
It would be a great addition to Debugger plugin to have possibility to see disassembly view of debugged program/C file :)
Capstone as a disassembler is worth to look into considering this issue to be resolved IMHO:
http://www.capstone-engine.org
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1038
This should fix #1164 , and replaces #1165.
BEWARE: I did NOT test this with libgit2 1.4, that I don't have yet. I might go to the trouble of building it and all, but for now this is a theoretical PR, but if libgit2 1.4 users can verify it it'd be great.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/1177
-- Commit Summary --
* git-changebar: Simplify libgit2 version checks
* git-changebar: Add support for libgit2 1.4
-- File Changes --
M git-changebar/src/gcb-plugin.c (88)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/1177.patchhttps://github.com/geany/geany-plugins/pull/1177.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1177
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/pull/1177(a)github.com>
Hi, I try to compile the Geany plugins from source on Ubuntu 20.04, but it is difficult to get all dependencies. I have to filter them out of the ./configure output. I'm still not able to compile all plugins.
It would be nice to have a list of necessary dependencies, preferably as c&p for different distributions.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1168
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/issues/1168(a)github.com>
I am using Windows 10 with Python 3.9.10 and rpy2 3.5.2. Here is my `rpy2.situation` output. R is install from CRAN including RStudio.
```
C:\Users\user>py -3 -m rpy2.situation
rpy2 version:
3.5.2
Python version:
3.9.10 (tags/v3.9.10:f2f3f53, Jan 17 2022, 15:14:21) [MSC v.1929 64 bit (AMD64)]
Looking for R's HOME:
Environment variable R_HOME: None
InstallPath in the registry: C:\Program Files\R\R-4.1.2
Environment variable R_USER: None
Environment variable R_LIBS_USER: None
Unable to determine R home: [WinError 2] Das System kann die angegebene Datei nicht finden
Unable to determine R library path: Command '('C:\\Program Files\\R\\R-4.1.2\\bin\\Rscript', '-e', 'cat(Sys.getenv("LD_LIBRARY_PATH"))')' returned non-zero exit status 1.
R version:
In the PATH: R version 4.1.2 (2021-11-01) -- "Bird Hippie"
Loading R library from rpy2: OK
Additional directories to load R packages from:
None
C extension compilation:
Der Befehl "sh" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
Warning: Unable to get R compilation flags.
```
This is not only an info about my environment but also gives a hint about the problem. Look at the conflicting informations about "R HOME".
# Problem from user perspective
The user get the information that `InstallPath` is there but `R HOME` not. Isn't that the same? I am not sure. The first is used on Windows the latter on unixoid systems?
# Technical perspective
Let's reproduce the problem
```
Python 3.9.10 (tags/v3.9.10:f2f3f53, Jan 17 2022, 15:14:21) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import rpy2.situation
>>> rpy2.situation.get_r_home()
Unable to determine R home: [WinError 2] Das System kann die angegebene Datei nicht finden
'C:\\Program Files\\R\\R-4.1.2'
```
Here you see a "heavy" error in the first output line and then just a "good" path in the second output line. The user doesn't understand that this are two trais where the frist failed and the second succeeded. So at the end is everything OK. But the user doesn't know that there is no problem anymore and that the error from first line isn't important anymore and solved by the "second line".
With adding some debug-print-code I found out that `r_home_from_subprocess()` is called first (and fails) and then `r_home_from_registry()` is called and succeed. That combination leads me to the wrapping function [`rpy2.situation.get_r_home()`](https://github.com/rpy2/rpy2/blob/8904d0c03ded74bfeedcab5c94c652df0d1a42a2/rpy2/situation.py#L173).
```
def get_r_home() -> Optional[str]:
r_home = os.environ.get('R_HOME')
if not r_home:
r_home = r_home_from_subprocess()
if not r_home and os.name == 'nt':
r_home = r_home_from_registry()
logger.info(f'R home found: {r_home}')
return r_home
```
I don't understand all details so please let me ask a question.
Is there a difference between the first line (`os.environ.get('R_HOME')`) of that method and that what happens in `r_home_from_subprocess()` (calls `R R_HOME` in shell)? I don't see a difference and because of that the code doesn't make sense (to me).
I am not sure about a good solution. But I want to suggest some points.
1. Don't use `os` instead of [`plattform`](https://docs.python.org/library/platform.html) to determine the current operating system.
2. (Not my favorite) Add an `log_excpetion` (default `True`) argument to `r_home_from_subprocess()` to optionally deactivate the log output when called from `get_r_home()`.
3. Remove all log output from `r_home_from_subprocess()` and `r_home_from_registry()`. The functions should raise an Exception (does rpy2 has its own Exceptions classes?). The quality of that solution depends on from where and how many other code locations this two functions are called. If the code search of GitHub is correct they are called only in `get_r_home()`.
If you can help with finding and deciding about a solution I would create a PR including some refactoring of that three functions. Are there any test units for that functions?
To summarize: I suggest to remove log output from the two sub functions and let them raise Exceptions. Handle that exceptions in the wrapping `get_r_home()`. If they are there improve the unittests.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3215
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3215(a)github.com>