[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gnunet] Questions on latest version
From: |
Christian Grothoff |
Subject: |
Re: [Help-gnunet] Questions on latest version |
Date: |
Wed, 3 Sep 2003 13:54:32 -0500 |
User-agent: |
KMail/1.4.3 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Like I've said in the past, the segfaults seem to be *very* unpredictable
> (I've certainly tried to find a reliable way to reproduce them in the
> past), and I don't habitually run processes through GDB.
> This time, I managed to get:
>
> Starting program: /usr/local/bin/gnunet-gtk
> [New Thread 1024 (LWP 799)]
> [New Thread 2049 (LWP 800)]
> [New Thread 1026 (LWP 801)]
> [New Thread 2051 (LWP 802)]
> [New Thread 3076 (LWP 807)]
> [New Thread 4101 (LWP 809)]
> [New Thread 5126 (LWP 811)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 799)]
> 0x08055d08 in _IO_stdin_used ()
> (gdb) ba
> #0 0x08055d08 in _IO_stdin_used ()
> #1 0x08055d03 in _IO_stdin_used ()
> #2 0x00000000 in ?? ()
>
> after trying to start a download. I forget what caused the segfault a few
> days ago, but in the past it's generally been from simply starting
> searches. Whether it's been for unusual keywords or common keywords or
> second searches or first searches, or what, has *never* been clear to me.
That trace doesn't really say anything (stack trace is garbage). Could be
pthreads (glibc-version?), could be anything. What platform are you using?
If it is Linux/x86, I'd suggest starting gnunet-gtk with valgrind (x86 memory
debugger), that may tell us which component is to blame. Yes, it will be slow
- -- on a P4 performance is acceptable. Do other GTK applications run nicely?
> > For me, it has been rock solid for the
> > last versions (what GTK version are you using???)
>
> The debian/stable package of libgtk1.2 (1.2.10-11)
> which has the filename of libgtk-1.2.so.0.9.1 (don't ask me how they
> come up with the numbers...)
Same version that my RH machine presumably uses (1.2-so.0.9.1), which does
work. Puzzling.
<Zaaaaap>
> What does the URI look like for SBlocks? AFAICT I've not seen one in any
> search response yet.
You won't unless you use gnunet-search-sblock (which should be integrated with
gnunet-search in the future). You need to specify a namespace (which you can
learn about out-of-band or by finding a directory that contains some other
SBlock in that namespace --- or by using your own namespace ID...) together
with the key. The resulting SBlock URL looks like this:
gnunet://afs/NAMESPACE-ID-IN-HEX/KEYWORD-ID-IN-HEX
Anyway, gnunet-search-sblock currently does not yet support the URI format and
only gnunet-gtk displays the result of an SBlock insertion in that format
(which is to the best of my knowledge the only place that actually uses it).
So it's kind of rare to encounter one of these at the moment :-)
<Zappppp>
> > The problem is, that this is the only practical way to get all of the
> > file-identifiers straight. gnunet-gtk allows you to freely compose
> > directories from files inserted earlier. A GUI is the only good answer to
> > a drag-and-drop build-my-directory problem. I just see no good way to do
> > this with a simple CLI.
>
> Unless the CLI programs are used as tools by other gnunet programs (eg:
> gui clients implemented with scripts). Not that I'd want the existing
> CLI utilities to be relegated to only being used that way, but you know
> what I mean. It's just a thought though, perhaps even that approach
> is flawed.
Well, I thought of clients linking against the "esed2" library (see current
CVS) which then provides functions for "insert file", "download file",
search, etc. That's how the CLIs and gnunet-gtk work. They are just some
small (or not so small for GTK) user interface plugged on top of that
library.
In the gnunet_util.h and gnuent_afs_esed2.h header files, you can find the two
definitions:
/**
* Get a GNUnet TCP socket that is connected to gnunetd.
**/
GNUNET_TCP_SOCKET * getClientSocket();
/**
* Inserts a file under the given name into the local GNUnet node.
*
* @param sock the socket to use to talk to gnunetd
* @param filename the name of the (incoming/source) file
* @param model the insert model used to
* update status information; points to NULL if
* no status updates shall be given, otherwise
* to a method that takes two size_t arguments
* (retrieved so far, total).
* @param model_data pointer that is passed to the model method
* @return top IBlock on success, NULL on error
**/
Block * insertFile(GNUNET_TCP_SOCKET * sock,
char * filename,
ProgressModel model,
void * model_data);
A trivial gnunet-insert would look like this in C:
#include <stuff>
int main(int argc, char ** argv) {
insertFile(getClientSocket(), argv[1], NULL, NULL);
}
Ok, this one has memory leaks and you probably want to pass a callback
(ProgressModel) to be informed about the progress, but I think this will be
much simpler than "fork(); exec("gnunet-insert");" with all of the code
around it to setup arguments and parse the output of the command
(stdout/stderr). The above should also be easier to maintain.
> > Easier to understand, maybe. Easier to use, definitely not. Also note
> > that gnunet-insert still can NOT do everything that the system may allow
> > you to do (like insert a file into your namespace of which you only have
> > the file identifier)
>
> I'd been wondering if that was the case. Your explanation that directories
> could point to files in either way made me try to figure out how
> gnunet-insert supported that, and I couldn't come up with anything.
Reason being that gnunet-insert can not do it (yet? what would the option look
like?)
> >. gnunet-gtk actually can do that, but it currently does not allow
> > you to specify "N" and "T". While I'd like both tools to be able to do
> > everything, it'll take some more time to get there.
>
> Hey, simply having the namespaces and directories is a great step
> forward already; I think as long as there's *some* way to do this stuff,
> that's the main thing. Not that I don't care how complete everything
> is, I'm just saying don't feel too pressured to get it all done straight
> away. Or something. Ahem.
Right, especially since we're talking tool support and documentation here. The
core of the system (gnunetd, routing, esed2 library) supports everything
already, and it will obviously take a while to push it to the state where
everything is *easy* to use.
C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/Vjjo9tNtMeXQLkIRArVCAJ9rjXwwq/xEvKEIOtJhFpifhVaG9QCfe40J
oj5+SQILuqlqKsn8fUdfvAA=
=kXkb
-----END PGP SIGNATURE-----