Hi, Jeroen.
Thank you for the responses. I've done some more work on this,
and I hope it will be helpful to you. I'm going to reply in a
separate message about the more recent work on porting.
>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.
I find that I crash very quickly when I have files shared, so I had
removed them from the available library, to allow the program to stay
up longer, while I tried out the different windows and setup functions.
But if I have no shared files at all, should there be able incoming
requests at all? There is nothing to download, so how would anyone
select a file on my system for download?
>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.
Ah -- I suspect that 99.99% of all users are using gcc for their
compiler. In that case, I now understand why I'm having problems,
and they are not. My compiler can't even be told to all this with
any switches - accesses to address zero are forbidden by the OS,
so it wouldn't do any good to give the compiler a switch to allow
it.
Once you add the assertion code to test for u->name == null, I think
you will see it happening on your test machine too.
>ps. Please cc to the gtk-gnutella-devel list so others might give there
input on this.
I will do that, starting with this message. I am not a member of the
list, so people will still have to respond to me directly.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 7:26 AM
To: Carl Erhorn
Cc: [EMAIL PROTECTED]
Subject: RE: [Gtk-gnutella-devel] urgent support request - Sun Solaris 8
for X86
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
