Activity for Gtk-Gnutella
-
tizizi created ticket #585
Recursive crash on armv7l
-
David created ticket #284
Allow to copy the magnet link of shared files
-
Raphael Manfredi modified ticket #584
Stack overflow in thread ADNS causes a crash 5 seconds after starting
-
Stefn Vincec posted a comment on ticket #584
Works fine now. Appreciate the fix!
-
I increased the minimum stack size for created threads in the "devel" branch. Are you able to fetch it, recompile, and tell me whether this is enough now?
-
Stack overflow in thread ADNS causes a crash 5 seconds after starting
-
Rui Chen created ticket #583
incompatible function pointer types build failure
-
Lucio Marinelli modified ticket #582
Error during DEB package generation.
-
Gtk-Gnutella released /gtk-gnutella/1.2.3/gtk-gnutella_1.2.3-1_amd64.deb
-
The error no longer appears when building the deb package with the latest GTKG 1.2.3 version!
-
-
-
-
-
zvezdochiot created ticket #143
1.2.3
-
ToSp1987 posted a comment on ticket #578
Hey, the Windows Installers are available. If you look at the ram... file above that you will see the 1.2.2. Just click on it and you will see more files for downloading.
-
Error during DEB package generation.
-
sean loony created ticket #581
Crash after closing tab with local search
-
dbus does not work
-
ups wrong thread.
-
Hi, dbus does not work. (Ubuntu 22.04.2 LTS) I compiled dbus support into gtk-gnutella. I start d-feet and search for gtk-gnutella. dbus using apps normaly appear like of org.foo.bar with Interfaces... in d-feet. gtk-gnutella appears under "session bus" as ":1.86" and "1.67" In the left window of d-feet there is no entry with org.gt-gnutella or similar only the ":1.86"/":1.87" I click one of those and in the right pane I got only: Address: unix:path=/run/user/1000/bus Name: empty unique name: empty...
-
Anjum Malik created ticket #579
Using GTK Gnutella only for private/local network (without internet)
-
Kirill Frolov Sergeevich created ticket #578
Windows installers are missing.
-
-
-
-
-
English FAQ/general updated!
-
Joachim Otahal posted a comment on ticket #577
Can you update http://gtk-gnutella.sourceforge.net/en/?page=faq ? And include the Windows example ;).
-
Actually I found the reason why it seemed not to work: http://gtk-gnutella.sourceforge.net/en/?page=faq#up1 The Wildcard is actually --all-- and not all or "--all--" So this "bug report" is invalid.
-
C:\Program Files (x86)\gtk-gnutella>set LANG=en C:\Program Files (x86)\gtk-gnutella>gtk-gnutella.exe Works! Thanks!
-
- no name - posted a comment on ticket #577
As gettext is use for the localization part. Would it work if you set the LANG variable to English for example: LANG="en" and then run the program from the same shell? https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html
-
1.2.1 Windows: Switching UI language to english missing
-
"Upload" directory is not recursivly scanned (on Windows, version 1.2.1)
-
Dmitry Butskoy created ticket #575
Recent glib2 defines G_NORETURN too.
-
PTHREAD_STACK_MIN no more constant by the recent glibc changes
-
Attached are the updated French and Turkish translations for version 1.2.1. Thanks for this new release!
-
Daniel Kolar created ticket #573
vmm_alloc_internal(): unknown thread allocating 4,096 bytes of core memory from signal handler
-
-
-
-
-
-
-
-
-
-
-
-
Current pop up is too obstructive, it jumps to the screen front every x minutes breaking for example movie full screen playback on Linux. It is nice You have added --no-expire switch, but regular user does not know about that. Better solution: A) closing the popup cause it not to appear until next start B) add checkbox "Do not show again" checkbox C) setting in Options on Linux the packages in repositories takes some time to update and building manually not everyone knows. Please consider suggested...
-
There's a new switch --no-expire that will stop with the popups in the new version 1.2.1 The new version 1.2.1 also takes now two years to expire. Please test with the new version.
-
Jon Martin created ticket #572
Most recent released version calls itself ancient.
-
Crash report under Fedora Linux
-
Crashed again. Assertion failed at src/lib/ripening.c:730 EDIT: Just looked through the crash log files (compiled from master), and in 4 crashes 3 where in this exact place with the same reason.
-
Crashed again. Assertion failed at src/lib/ripening.c:730
-
Another crash. By diff the files it looks like this is in a different place from the previous.
-
Crashed again with the latest master
-
John Wandsworth posted a comment on ticket #570
Hi, wanted to add some new crash logs, thanks.
-
Completed French & Turkish translations
-
wanted to add this latest crash log, because it doesn't always produce a crash log when it crashes.
-
Windows crash
-
Suggestion: Invoke external program on search results
-
Thanks for the explanation. I now also agree that it's not a bug. :-)
-
100% goes to 0%
-
That's most probably because the file failed its SHA1 checking once completed, probably due to some bad host yielding incorrect data. When this happens, gtk-gnutella uses the Tiger Tree Hash (TTH) tree to determine which parts, among the file, are correct and do not need to be re-downloaded and which must be pruned away and re-fetched. The SHA1 is global but the TTH is a tree built by assembling hashes of smaller parts, hence we are able to only discard the chunks failing the Tiger Hash (granularity...
-
I just saw it happen in front of my eyes XD The file gets then re-downloaded fine :-)
-
100% goes to 0%
-
Crashed again with the latest master
-
Now It crashed for no reason... Attaching log.
-
I can crash the latest version of gtk-gnutella: 1- click "What's new?" button 2- Change the default filter (i set it to video) 3- Click again on the "What's new?" button. gtkg crashes
-
Thanks for the explanation. Already updated. Let me run it for a while. Let's see if the issue happens again :-)
-
I have pushed commit a699adddb298cb67405bfce987ebb94ef92dbd82 on the "devel" branch and it should fix these particular crashes you are having in fi_pick_rarest_chunk(). Please let me know how it behaves for you. Note that these crashes have nothing to do with the ones you had when you opened this bug report: the assertion failure you originally had was in another piece of code, totally unrelated. Let's continue to track progress here anyway, as the original source of your crashes is still unknow...
-
The good news is that these are all crashing at the same place with the same assertion failure, and I have enough information now to know that the logic there is flawed: not the assertion, the logic! That's what we could call a bug :-) So now I simply need to get enough time to dive into the code and fix it. I will keep you posted when I have committed a fix on the "devel" branch.
-
It crashed again today.
-
crashed again. Not sure if it's related as i ran out of space in the partition where i was saving the files. Attaching the logs
-
I am not seeing libbfd in that list... which means -lbfd was probably not passed to the linker and BFD suport probably not compiled in. Because you installed BFD after running Configure (through build.sh), you need to go back to the root source directory and run: make clobber ./build.sh again. Once the build is done, make sure BFD is indeed compiled in by running: ldd src/gtk-gnutella | grep bfd If you see libbfd in there, there you can then sudo cp src/gtk-gnutella /usr/bin/ and wait for the crash,...
-
demanuel@archlinux ~/Downloads> file /usr/bin/gtk-gnutella /usr/bin/gtk-gnutella: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=ac34a69a83443acca5d27591e89e78767d4addd5, for GNU/Linux 3.2.0, with debug_info, not stripped demanuel@archlinux ~/Downloads> ldd /usr/bin/gtk-gnutella linux-vdso.so.1 (0x00007ffc774fa000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00007f87b9a18000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0...
-
Linux crash
-
Unfortunately, your stack in the crash log is not correct, hence it is difficult for me to understand what is exactly going on. Did you strip your binary? Can you do a: $ file /usr/bin/gtk-gnutella to make sure it has debug_info and is not stripped. Also can you do a: $ ldd /usr/bin/gtk-gnutella to make sure it is indeed linked against the BFD library? Without a proper stack trace, I cannot investigate easily why this is happening.
-
Coredump attached
-
Just crashed now. Logs attached:
-
Open ports for iptables
-
Open ports for iptables
-
Linux crash
-
Waiting to see whether it happens again after a clean recompile.
-
I build it again, checked the output: Checking whether the BFD library is available... yes. And enabled the core dumps. I have the gtkg running now. I believe this incident can be downgraded as i don't have a repro case. I'll update it here next time it crashes.
-
On Arch linux, it should be the binutils package. Try it to see if the BFD library is found by Configure (launched from build.sh).
-
My distro (arch linux) doesn't have this package binutils-dev :-( https://www.archlinux.org/packages/?q=binutils I will recompile it again. Let's see if it improves.
-
Linux crash
-
Linux crash
-
You have me puzzled. You are hitting an assertion failure that looks impossible. Reading the code where the assertion fails, and proofreading again the condition that would need to be present for that assertion to fail, I see no way this can happen. But it does... May I suggest two courses of action here: - install the binutils-dev package so that you get the BFD library and we can have stacktraces which include source code location. - go to the top of gtk-gnutella's sources and run: $ make clobber...
-
After the GTKG crashed once more i tried to start it in the command line: demanuel@archlinux ~/.gtk-gnutella> gtk-gnutella 20-11-13 13:05:35.157 (WARNING): cannot find symbols_load_from() in the loaded symbols 20-11-13 13:05:35.157 (WARNING): garbage symbols, trying with pre-computed "/usr/lib/gtk-gnutella/gtk-gnutella.nm" 20-11-13 13:05:35.276 (WARNING): Another gtk-gnutella supervisor is running as PID 2422783 20-11-13 13:05:35.276 (MESSAGE): If PID 2422783 is not a gtk-gnutella process, run: 20-11-13...
-
Linux crash
-
OSX v 1.2 crashing
-
Yes, it's a bug I've hit myself, but so far I have been unable to reproduce it. It happened once, and then poof, it disappeared. Not having enough context, I'm not able to look at the logic to understand the flaw in the code. I have added extra logging at the place where this triggers on the "devel" branch to help me the next time it happens. Unfortunately, the OSX Build on Travis CI is broken, so I cannot supply you with a binary to test it and help me debug it. And I do not have any Apple box to...
-
Sol Terlson Kennedy created ticket #566
OSX v 1.2 crashing
-
GTKG's magnet parser does not recognize the xt.n syntax. I'm still wondering as to what it would do with various xt.n parameters knowing that it currently only supports the urn:sha1: ones. Why not search for each urn:sha1 ? Conceivably, it would make sense to have xt.n recognized and it would make sense for a magnet to hold different hashes for different protocols, all in one magnet. But this is not what you are talking about here in your request. Correct, that's not what i'm referring to. Magnet...
-
Thanks! Installed.
-
GTKG's magnet parser does not recognize the xt.n syntax. I'm still wondering as to what it would do with various xt.n parameters knowing that it currently only supports the urn:sha1: ones. Why not search for each urn:sha1 ? only urn:sha1 is supported? is it possible to add support to urn:bitprint ? Conceivably, it would make sense to have xt.n recognized and it would make sense for a magnet to hold different hashes for different protocols, all in one magnet. But this is not what you are talking about...
-
GTKG's magnet parser does not recognize the xt.n syntax. I'm still wondering as to what it would do with various xt.n parameters knowing that it currently only supports the urn:sha1: ones. Also, what would it mean to have two urn:sha1: listed, especially if they are different... ? Conceivably, it would make sense to have xt.n recognized and it would make sense for a magnet to hold different hashes for different protocols, all in one magnet. But this is not what you are talking about here in your...
1 >
