Hi,
reply below quoted text.
> Hello.
>
> So here's the conflict:: It's clear that the status routine requires that
> the
> entry in the queue never have a null u->name. But upload_create *_never_*
> copies any data into that structure member. So where is it supposed to be
> added, and how come we never call that function?
Can't answer that right now. But it is probably looked up in the local
library. If the file isn't shared the name is probably null (same goes for
SHA1)
>
> I set a breakpoint at line 590 in sockets.c, which calls upload_create,
> because
> I wanted to see the actual data read from the socket that triggered the
> request.
>
> NOTE: 'first' is the string that was read from the socket that triggered
> the creation of the upload request. It's important to know that I have no
> files shared at all during these tests, so that there is no reason for an
> upload request to be passed to me.
>
> first = 0x8af7860 \
> "GET /uri-res/N2R?urn:sha1:C3VM57CRTSY5JLLDSY64I62KH62HHOLM HTTP/1.1"
>
> After the error occurred, I unwound the stack one level, to put me in the
> parq_upload_find() function (see level 5 above), where I could access the
> request structure.
>
> NOTE: 'u' is the request structure. Below is a dump of the struture
> members.
> Notice that both the 'name' and 'sha1' members are null. Certainly by
> the time we get to the status request, one of them should not be null.
> Or should they?
Well, as I said, when they are not availabe in the local library, name and
SHA1 are not assigned. In which case they will be null.
>
> *u = {
> upload_handle = 0
> status = GTA_UL_HEADERS
> socket = 0x8cc8380
> error_sent = 0
> io_opaque = (nil)
> parq_opaque = (nil)
> file_desc = -1
> bio = (nil)
> buffer = (nil)
> bpos = 0
> bsize = 0
> buf_size = 0
> index = 0
> name = (nil)
> file_size = 0
> start_date = 0
> last_update = 1065076166
> ip = 2449381912U
> user_agent = (nil)
> skip = 0
> end = 0
> pos = 0
> last_dmesh = 0
> sha1 = (nil)
> total_requested = 0
> http_major = 0
> http_minor = 0
> keep_alive = 0
> push = 0
> queue = 0
> accounted = 0
> parq_status = 0
>
> At this point, I have no idea how we got into this state. If it is a
> normal state, then there should be a conditional statement that only
> calls the gm_snprintf() function when the value for name is not null.
>
> Is is possible that the GNU compiler allows references to null pointers
> without causing segfaults? Solaris certainly doesn't, and the only other
> system that I am aware of that does is HP, and even then it has to be
> told to do that. By default, it triggers a segfault, just like Solaris.
Yes it does. For example when you do a printf("Test: %s\n", NULL); it will
print "Test: (null)". That is probably why the problem wasn't triggered
before
> By the way, I ran a diff against the source code I built from, and the
> original tar source files that I downloaded. I did not touch the
> uploads.c file at all during my porting. They match exactly, so nothing
> was changed.
>
> The same is true for the parq.c file. Since these are the files that
> manage these variables, there should be nothging wrong, or all the
> various people who run this code should also be crashing. So I am
> very confused.
I'd like to keep ( / make) the code portable. Can you post a patch with
your changes? Perhaps they should be applied to CVS to assurre
portability.
I'll add some extra assertions to the code to assure that name != null,
than this should trigger the problem also locally. Also there is no need
to find the parq position if the name == null. I'll change that in CVS too
tonight.
- Jeroen
ps. Please cc to the gtk-gnutella-devel list so others might give there
input on this.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gtk-gnutella-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
