Activity for Dmitry Butskoy
-
Dmitry Butskoy posted a comment on ticket #19
Shunsuke Matsumoto wrote: OPTIONS -4, -6 Explicitly force IPv4 or IPv6 tracerouting. By default, the program will try to resolve the name given, and choose the appropriate protocol automatically. If resolving a host name returns both IPv4 and IPv6 addresses, traceroute will use IPv4. Yes, surely it must be changed. Thanks for the report.
-
Astrid Yu wrote: Since I'm using it non-interactively, retrieving that information is a bit more of a hassle. Well, maybe just use wrappers? Wrapper is a more correct way here, especially given the non-interactive nature of use. In addition, this is a more universal way, because allows you to add the necessary output functionality without the need for any change in the utilities involved. Sometimes the writing of the wrappers looks difficult or bulky at first glance, but this is a really correct...
-
Astrid Yu wrote: I know there is a way to explicitly provide a source IP and interface. However, if you don't do that, unless I'm mistaken, I don't believe there is a way to tell what source IP, starting port, and interface is being used. I've looked through the |--help| and I don't think I've found any flags for that, either. ... ||Ideally, I'd like the header to look something like this instead: |traceroute to google.com (64.233.177.113), 30 hops max, 60 byte packets, source IP 192.168.192.168:33434,...
-
Well, there is already such a patch that has been made for a long time by ALTLinux Distro. That distribution for some reason professes more pedantic warning options, and just like you, uses -W (or -Wextra) by default. Most of the warnings that you reported are taking place due to the fact that the -Wsign-compare option is activated (which is part of the -Wextra set). For the moment, -Wsign-compare is not considered by leading distributions as a mandatory compilation option. For example, neither Fedora...
-
Sebastian Moeller wrote: FreeBSD's traceroute for IPv4 (a different bninary from traceroute6) has a very interesting diagnostiuc/debug mode that allows to record and then analyse modification to the IP header along a path: Unfortunately we don't have access to the raw IP headers anyway due to implementation limitations. All information is obtained only by the recvmsg(2) system call with the MSG_ERRQUEUE flag set. This way allows unprivileged users to use "udp" and/or "icmp/echo" traces without having...
-
RFC-3484: Traceroute should defaults to IPv6 instead of IPv4 if possible
-
Fixed in 2.1.6 .
-
Enable large file support (LFS)
-
Jan Macku wrote: Traceroute defaults to IPv4 addresses even when IPv6 addresses are available. While there is the traceroute6 option, The RFC below appears to indicate that this should not be the case. RFC-3484 - Default Address Selection for Internet Protocol version 6 (IPv6) https://www.rfc-editor.org/info/rfc3484 Well, sounds reasonable, since ping(8) has long used the results of getaddrinfo(3) to determine the default address family. Can you imagine some negative use cases in practice due to...
-
Taoyu Saijo wrote: To be compatible with large file support shall we consider compiling the project with the following flags? |-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE| |Traceroute does not use filesystems in any way in its work. So nothing special in this context -- just use the standard compiler flags from your Linux distribution. ~buc |
-
Add option to display MSS TCP option
-
Very thanks for the idea! Implemented now in 2.1.4
-
Francois wrote: Existing traceroute -T -O mss=xxx lets a user specifies the value within the TCP MSS option. To detect issues with clamping (routers rewriting the MSS with a different value), it would be nice to display the MSS value as found in the ICMP and TCP replies. Today this can be achieved by running a tcpdump at the same time traceroute is running. Attaching a patch with a proof of concept. What do you think? Thanks for the info! Currently we only parse TCP flags and only from the final...
-
Incorrect placement of asterisks for probe timeouts
-
RFE: send many, wait for few
-
I believe since the version of 2.1.0, this (or similar) feature is now implemented. See "-w" option description in manual. (IOW, no more wait for long replies when there are already some fast replies received). So close now.
-
Sudden "send: No route to host" with 6.1.x kernels
-
Thenks for fix and report. Confirmed with kernel-6.2.0 on Fedora Rawhide. Fixed in traceroute-2.1.2
-
Tyler wrote: Even with the 3 hop default this is possible: |$ traceroute -m 3 45.56.99.171 -n traceroute to 45.56.99.171 (45.56.99.171), 3 hops max, 60 byte packets 1 * * * 2 198.19.123.1 19.705 ms * 19.674 ms 3 * 198.19.110.1 26.045 ms 27.674 ms | I only noticed this because I was trying to parse traceroute output so I was looking more closely... This isn't expected behavior right? Yes, it is expected behaviour. The IP address is printed at the first answered probe in a line. When the first answered...
-
Recent glib2 defines G_NORETURN too.
-
PTHREAD_STACK_MIN no more constant by the recent glibc changes
-
Crash report under Fedora Linux
-
A better way to fix the issue. Does not lead to impossibility to shrink the window in general, and the same time fixes the issue reported at https://github.com/v1cont/yad/issues/107 . The problem is the wrap mode when just "yad --text=TEXT" is invoked (without any particular dialog options). When the wrap mode is set, gtk always reserves a space for the maximum possible amount of such wraps, which is computed by the number of the space characters in the text. It explains the appearing of the extra...
-
Tomasz Kłoczko wrote: [bugs:#12] https://sourceforge.net/p/traceroute/bugs/12/ traceroute VCS repo? Status: open Group: v1.0 (example) Created: Mon Mar 15, 2021 08:41 PM UTC by Tomasz Kłoczko Last Updated: Mon Mar 15, 2021 08:41 PM UTC Owner: nobody Is it anywhwere some public VCS repo with traceroute source code? If not is it possible to crrate it instead on sf.net on github or gitlab? (those two it have way better rest interface to download axact commits over that interface) You already asked it...
-
traceroute VCS repo?
-
Simple test case: ./yad --text=foo --use-interp='bash -c "%s"' --button='bar:echo $YAD_GEOMETRY'
-
Proposed patch. There is a recommendation not to use g_setenv() function directly, and use a proper envp array for g_spawn_(sync|async)(). The current code uses g_spawn_command_line_(sync|async)(), which do not handle envp argument. Fortunately, both functions are actually simple wrappers in glib2 code, which can be easy ported as needed. Thus in src/util.c there is new static function do_run_command(), and run_command_(sync|async) become just wrappers for it. (Note, last "if (!retval)" statement...
-
RFE: implement YAD_GEOMETRY environment variable.
-
But if the same time the vertial scrollbar is in use, it overlaps the window at the right border until you specify --vscroll-policy=always, in which case gtk3 adds proper space itself...
-
a piece of code you patched, not needed at all anymore Seems still needed, according to https://github.com/v1cont/yad/issues/107 and the tests below: Test 1: yad --no-buttons --text=justsometext Test 2: yad --no-buttons --text="just sometext" Test 3: yad --no-buttons --text="just some text" Note increasing bottom area. Yet the code removed was written for some reason... If the issue affects the dialog text only, and dialog texts are not intended to be wrapable, the solution might be to drop gtk_label_set_line_wrap()...
-
It seems the patch does not fix the issue itself (just some side effect here). There are another test case with text-info, utilising stdin only: echo -e 'aaa\nbbb\nsome very very very very very very long string' | yad --text-info IOW, don't apply for now.
-
Add .patch to filename :)
-
Fix justification settings
-
The proposed patch introduces two list options: --preselect-value=TEXT and --preselect-column=NUMBER . Each row is checked on input, and if it has a column (default first, altered by --preselect-column) with the value specified (TEXT), cursor is pointed to this row and the list is scrolled properly. This selection is made only once, independedly of the type of input (stdin and/or cmdline). It is a most convenient way just to use a column text matching, since users always know an exact value they...
-
RFE: implement an option to initially select a row (set cursor) in the list
-
It was not so hard -- see the patch attached. Both code and manual. I've chosen the option name "css" and variable name "css_data". "--gtkrc" takes precedence. Feel free to change as needed.
-
Critical assertion on lists filled by cmdline under some circumstances
-
Besides that, with --hscroll-policy=never the width of the window (fe. list) seems determined by its content, which is very useful. But if the same time the vertial scrollbar is in use, it overlaps the window at the right border -- ie. user should increase width by the horisontal size of the vertical scrollbar...
-
wrong check for hscroll-policy option's name
-
I've found a commit on github for this (a year ago), but seems not applied yet... 6f3f128
-
RFE: implement an option to load CSS from the string
-
fix some gcc and clang compiler warnings
-
window-icon: avod unwanted access to an extraneous file.
-
crash on some combination with --sep-column
-
Add new-line for --print-xid
-
Works fine. Additonally, an issue when an actual size was differ with specified (because of adding the border sizes to it) is gone.
-
I'm worry about other places where the same issue can happen. For example, in src/form.c : set_field_value (i, ""); and then in set_field_value() there are calls to g_strsplit(), fe.: s = g_strsplit (value, options.common_data.item_separator, -1); etc. etc. etc.
-
I've discovered that shrinking is still possible if I set the width by "--geometry" option, rather than "--width". I the current behaviour is a feature (ie. not a bug), then it should be mentioned in the manual. Something like: initial width and height can be set either by "--geometry", or by "--width" and/or "--height". Difference is since "--width" is used, the window cannot be shrinked to less width and height (both) than specified. Certainly the mention that "--width" is ignored in favor of "--geometry"...
-
Cannot shrink by width since 0.41.0, gtk3
-
g_strsplit: a broken usage
-
Mark, Try also to reproduce with Adwaita icon theme, and/or with a current 1.1.15 but recompiled with -Dalignbytes=16 (and breeze icons). It will help to determine whether it is still the initial issue of this bug or something new (inspired by some other changes in the devel branch). If new, probably a new bug ticket should be filed then.
-
I have pushed commit 7c35a97e9393ba58120eb170c64e1819976a96d9 to do just that. Can you please verify that it is now working correctly, with no manual tweaking of Configure? Works OK.
-
Some notes: Apparently starting early 2020, the system malloc() was configured to * on MAX(2 * sizeof(size_t),__alignof__(long double)). Actually, Glibc uses 2 * sizeof (size_t) at least since 1996 ! :) And alignof long double appears at 2006! The fact "there is no long double in GTKG" does not affect the way how Glibc's malloc compute its alignment internally. IOW in general we should respect its __alignof__(long double), but OTOH it seems actually affect power32 systems only... Since the C11 standard...
-
Some notes: Apparently starting early 2020, the system malloc() was configured to * on MAX(2 * sizeof(size_t),__alignof__(long double)). Actually, Glibc uses 2 * sizeof (size_t) at least since 1996 ! :) And alignof long double appears at 2006! The fact "there is no long double in GTKG" does not affect the way how Glibc's malloc compute its alignment internally. IOW in general we should respect its __alignof__(long double), but OTOH it seems actually affect power32 systems only... Since the C11 standard...
-
Some notes: Apparently starting early 2020, the system malloc() was configured to * on MAX(2 * sizeof(size_t),__alignof__(long double)). Actually, Glibc uses 2 * sizeof (size_t) at least since 1996 ! :) And alignof long double appears at 2006! The fact "there is no long double in GTKG" does not affect the way how Glibc's malloc compute its alignment internally. IOW in general we should respect its __alignof__(long double), but OTOH it seems actually affect power32 systems only... Since C11 standard...
-
Some notes: Apparently starting early 2020, the system malloc() was configured to * on MAX(2 * sizeof(size_t),\ __alignof__(long double)). Actually, Glibc uses 2 * sizeof (size_t) at least since 1996 ! :) And alignof long double appears at 2006! The fact "there is no long double in GTKG" does not affect the way how Glibc's malloc compute its alignment internally. IOW in general we should respect its __alignof__(long double), but OTOH it seems actually affect power32 systems only... Since C11 standard...
-
Strongly say, C11 standard introdiced "max_align_t" type (declared in stddef.h when "gcc -std=c11"). For x86_64, __alignof__(max_align_t) is 16 (with sizeof of 32). Rust use this type with its bindings with the system library (glibc for Linux). Probably other non-C code might use it too. IOW it seems that for modern systems the correct way to obtain "alignbytes" is check for "__alignof__(max_align_t)" by C11-compliant compiler. More portable way is just to follow modern Glibc's malloc: "MAX((2*sizeof(size_t)),__alignof__(long...
-
Configure with "-Dalignbytes=16" fixes the issue. By default, the value of global C macro MEM_ALIGNBYTES is computed by Configure, and currently gives (for x86_64) the value of 8 . This value is then used including by xmalloc.c for its alignment. Contraring to GTKG's, Glibc's malloc now uses alignment of 16 for 64 bit systems. Actually, it is computed there as "MAX((2*sizeof(size_t)),__alignof__(long double))". It is likely enough (due to its nature etc.) that Rust relies on this "standard" system...
-
librsvg2-2.45.5 is OK librsvg2-2.45.6 is crash (Since 2.45.6 they boast that all the code is rewritten in Rust and some code reorganization is performed. Nothing to search deeper.) Are there any hints how to debug GTKG's malloc implementation? Some notes also: Gtk2 uses gdk-pixbuf2 library for icons, which seems to use appropriate per-icon-type loaders at runtime. For svg it is /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so , which is linked against /usr/lib64/librsvg-2.so.2 . This...
-
Issue gone when compiled with system malloc (ie. -Dusemymalloc=false). New librsvg2 is written mostly in Rust (instead of C), which can be more strict about memory alighnment etc... Going to try to bisect since librsvg2-2.44.14 (which is rust too, but reported worked).
-
It is actually duplicate of #561
-
Catch something under CentOS-7 with backported librsvg2-2.48.2 and breeze icon theme (5.68.0). A bit different, but reproduced well. A half of success anyway :)
-
Additionally, it could be useful to play with locale settings. The crash seems to be somewhere in the deep Rust's locale-related code. Try to set, for example, "LC_MESSAGES=C" in environment (and maybe LC_ALL, LANG etc.etc.) to see whether it changes something or not.
-
Considering Kubuntu's and Fedora's stack traces, it seems that it is the same bug, related to how gtk2-->gdk2-->gdk-pixbuf2-->librsvg2 handle ".svg" images. It is quite impossible to investigate source code deeper, since librsvg2 now use Rust instead of C . It is interesting whether GTKG works with an icon theme without svg files (/usr/share/icons/...) . If it crashes when svg is present only, than what icon exactly triggers the crash (or any of them).
-
Thanks. Tested (remotely :( ) under Fedora-32 and Xvfb -- no crash (even with all the breeze themes installed). OTOH a similar bug is already reported for Fedora-32 . Mark, Could you please: 1) test under "trivial" gui environment -- ie. "startx -- :1" from a console and run "gtk-gnutella" from the lonely xterm window; 2) try to change icon theme (to fe. adwaita, as reported in Fedora bug). This way we will take a step in determining what triggers the error.
-
Thanks. Tested (remotely :( ) under Fedora-32 and Xvfb -- no crash (even with all the breeze themes installed). OTOH a similar bug is already reported for Fedora-32 . Mark, Could you please: 1) test under "trivial" gui environment -- ie. "startx -- :1" from a console and run "gtk-gnutella" from the lonely xterm window 2) try to change icon theme (to fe. adwaita, as reported in Fedora bug) This way we will take a step in determining what triggers the error.
-
Thanks. Tested (remotely :( ) under Fedora-32 and Xvfb -- no crash (even with all the breeze themes installed). OTOH a similar bug is already reported for Fedora-32 . Mark, Could you please: 1) test under "trivial" gui environment -- ie. "startx -- :1" from a console and run "gtk-gnutella" from the lonely xterm window 2) try to change icon theme (to fe. adwaita, as reported in Fedora bug) This way we will take a step in determining what triggers the error.
-
Which particular files in .config and gtk2 would be most useful? Hard to say. Ideally, if it can be reproduced under some newly created user (ie. still no any private data), then just all the homedir. Or copy the "crashed" homedir to such a user and try to strip it (ie. while crash is still present). The bug can be related to some specific (user or distro) gui preferences. Fe. under Fedora it seems to be some non-standard icon theme. Maybe something else too.
-
Could also be related to https://sourceforge.net/p/gtk-gnutella/bugs/562/ Very likely. Mark, It seems that only you for now has a repeatable crash. Could you preserve the crash environment -- ie. ~/.gtk-gnutella plus some ~/.config and gtk2-related files etc.etc.etc ? (gtk2 might be needed since the bug report above shows that the issue might gone when user change to default gtk2 icon theme). Then it could be fine to reproduce the crash under a new clean user with a minimal copy set of that environment...
-
Not so obvious here. Either the backtrace might explain something, or just wait for an advanced user with repeateable crash. :)
-
Occasional crashes somewhere in librsvg library in Fedora-32
-
During the investigation of the bug #558, I've madea build by clang-10. There is a couple of some warnings, produced by clang-10 but not gcc-10, which might be interesting anyway. Prepared log file attached.
-
No more warnings with gcc-10 . File README still not fixed for FSF address... 1.1.16 anytime soon?
-
To not open a new bug: src/lib/smsort.c file seems not needed to be executable...
-
Update GNU license file for new fsf address
-
since asm() is not used in GTKG yet and I would therefore need to add extra portability for it in case one uses another compiler than gcc. If a compiler understand an "attribute" statement, it is most likely it understand "asm" as well. At least in such a primitive form. :)
-
OK, no more crash at startup. BTW, gcc-10 prodices some warnings at compile time, see log attached.
-
static int NO_INLINE alloca_stack_direction_compute(void) helps as well. Considering "asm" statement, gcc's manual say for function attribute "noinline": This function attribute prevents a function from being considered for inlining. If the function does not have side effects, there are optimizations other than inlining that cause function calls to be optimized away, although the function call is live. To keep such calls from being optimized away, put asm (""); in the called function, to serve as...
-
Further investigations about part 2 :) Bisect compiling of the code partly with and without "-finline-functions" shows that the problem is "src/lib/alloca.c:alloca_stack_direction_compute()". Two kludges possible: either compile this file with "gcc-10 -O2 -finline-limit=29" (the limit of 30 leads to crash), or put asm(""); statement in the function (which is even recommended by gcc's manual, aka Linux kernel's barrier() etc.) Computing stack direction at runtime nowadays... hmm... brr... it is not...
-
I am reluctant to force no-inlining. Nope, the flag "-finline-functions" does NOT drop inlining. It is about "agressively, unneeded, total" inlining, traditionally suitable for -O3 "non-default" optimization level. Consider the output of, say, gcc-8: gcc -c -Q -O2 --help=optimizer | fgrep inline -finline [enabled] -finline-atomics [enabled] -finline-functions [disabled] -finline-functions-called-once [enabled] -finline-small-functions [enabled] IOW inlining IS enabled, but "-finline-functions" is...
-
Proposed patch for Part 1 issue.
-
Double reason. Part 1. "Configure" script checks gcc version in statements like case "$gccversion" in 1*) something for gcc-1.x ;; ... esac This matches the version of gcc-10 ... :) As a result, a wrong flag "-fpcc-struct-return" is added, which leads to crash on div(3) function. Such a crash takes effect when compiled with "-O0" or "-O1" only. Part 2. Since gcc-10, "-O2" optimization level includes "-finline-functions" (previously in "-O3" only). It leads to crash immediately at startup (in "allocate_stack()...
-
Just trying with optimization options etc. a bit more...
-
Well, crashes when compiled by gcc-10 in RHEL-7 environment (near Fedora-18 afair). Compiled with -O0 produces different crash -- looks like stack is overwritten by a garbage somehow. Probably something useful might be found in gcc-10 release notes? (ie. removing some old compatibilities etc.)
-
What's the version of the lib holding allocate_stack()? https://mirror.yandex.ru/fedora/linux/releases/32/Everything/source/tree/Packages/g/glibc-2.31-2.fc32.src.rpm
-
An output of 1.1.15 compiled by clang-10 (a test run in environment without X server)
-
Coredump of the same latest devel, but compiled with "usemymalloc=false". Note a bit simple stack trace... :)
-
Coredump of the latest devel from github source.
-
Coredump of the ordinary F32 package (1.1.15 plus malloc_usable_size() patch)
-
Could you try to compile the "devel" branch to see if it behaves differently? Crashes too: The latest development snapshot, with F32 and gcc-10, crashes as well.
-
Could you try to compile the "devel" branch to see if it behaves differently? Crashes too: The latest development snapshot, with F32 and gcc-10, crashes as well.
-
Tried with "usemymalloc=false", crashes too (gcc-10) But there is a bit difference -- when "usemymalloc=true" (default), gtk-gnutella crashes when starts under root and under unpriveleged user. With "usemymalloc=false", gtk-gnutella crashes under unprivileged user, but complains (about "no work under root!") and exit when invoked under root (without crash).
-
More info: The same package compiled under Fedora 31, with gcc-9 and glibc-2.30, works fine BOTH under Fedora 31 and Fedora 32 (ie. under F32's glibc-2.31 runtime environment all seems OK). The package compiled under Fedora32, with gcc-10 and glibc-2.31, crashes at startup, BOTH under Fedora 31 (with glibc-2.30 runtime) and under Fedora 32. The correspond downstream bug is https://bugzilla.redhat.com/show_bug.cgi?id=1834318 , with some backtraces. The same package compiled with Clang-10 (instead...
-
Crashes immediately on Fedora 32, with gcc-10 and glibc 2.31
-
stats.c: do not use name "statx" to avoid broken referencing with the system one
-
pattern.c: fix compiling with old gcc (version 4.4)
-
pattern.c: forgot to add endian.h header
-
It would sound reasonable if I'll choose some own site for upstream. But for now,...
-
1.1.8 does not compile with gnutls-2.8.5 (RHEL6)
-
1.1.9 broken to compile with gcc-4.4 (RHEL6)
1 >
Gen AI apps are built with MongoDB Atlas
Atlas offers built-in vector search and global availability across 125+ regions. Start building AI apps faster, all in one place.