I think this problem has to do with a different behaviour of the
glib GIOChannel callback on FreeBSD and linux. Don't ask
me what exactly the problem is, I think there might still be
some commented out code in pipe.c in the callback.
Also, I don't have FreeBSD, so I can't really debug this
myself. I am afraid you'll have to do this yourself.
Alternatively, in main.c, main(), remove the call to pipe_create
() and pipe_unlink(). The pipe is just an extra, it's not
necessary at all.
The junk pointer error msg I can't make sense of either. where
does that msg come from?
The last one (searchlist_destroy) I wouldn't worry about.
Sorry I can't be more helpful.
Cheers
-Tim
PS: I don't think that the fact whether a core is running or not
matters in this case. Does it? I wouldn't think so.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think this problem has to do with a different behaviour of the
glib GIOChannel callback on FreeBSD and linux. Don't ask
me what exactly the problem is, I think there might still be
some commented out code in pipe.c in the callback.
Also, I don't have FreeBSD, so I can't really debug this
myself. I am afraid you'll have to do this yourself.
Alternatively, in main.c, main(), remove the call to pipe_create
() and pipe_unlink(). The pipe is just an extra, it's not
necessary at all.
The junk pointer error msg I can't make sense of either. where
does that msg come from?
The last one (searchlist_destroy) I wouldn't worry about.
Sorry I can't be more helpful.
Cheers
-Tim
PS: I don't think that the fact whether a core is running or not
matters in this case. Does it? I wouldn't think so.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm having the same problem with FreeBSD 4.7 and ed2k_guy 0.3 und 0.4. version 0.2 works fine.
I followed your advice and commented out the pipe_create and pipe_unlink calls. It works now, and I'm happily using the 0.4.0 Version built on Jan 6 :-)
Maybe you could make this a configure switch?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have just checked some code into CVS that spits out a lot of
debugging information in case it has been compiled on
FreeBSD. It will also disable the pipe after 1000 re-creates.
If you are using FreeBSD, please be so kind and compile the
latest CVS version, and then send me the output you get on
the terminal when you start the GUI. This would help me a lot
in tracking down this bug. I think it is better to fix this than to
switch this feature off.
Thanks! :-)
Cheers
-Tim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This one needs a better fix. With 0.6.0 (and current CVS) and FreeBSD
4.9-RELEASE, ed2k_gui hangs on this pipe after startup before even
opening the gui. Not creating it in the first place works around this, but
it's obviously not a fix. Anyway, this happens regardless of
O_NONBLOCK or not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This used to be fixed at some point with gtk/glib-1.2, but it
seems that it broke again on FreeBSD when we did the port to
gtk/glib-2.x.
Truth is though that this is unlikely to get fixed until some
FreeBSD person sits down with a cup of tea and some biscuits
and tries to fix it, as I don't have access to a FreeBSD system
(the sourceforge compile farm one is up ca. 1 hour per month,
and then completely unresponsive, and thus not really usable
for debugging stuff like this unfortunately).
-Tim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
lioux is probably both busy or has been reluctant to upgrade the port
due to the reappearance of this bug. I'll make sure the port gets
updated to 0.6.1 once it's released.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, the core cannot be updated in ports because 0.51.2 has
issues with FreeBSD's linux-runtime-compat and crashes with 'Bad
system call' shortly after startup.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
oh, I didn't know that. What about 0.50.1? Same thing?
In any case, I'll try to get someone to build a native x86
FreeBSD version, or do it myself if I manage to free a
partition somewhere. No promises though.
Might it be related to the fact that it's statically linked?
Here's a dynamically linked version in case you want to try
that (linux/x86):
0.50.1 is the current version in ports, it works fine. Your dynamically
linked core works fine, too!
However, we'd probably indeed need either a native binary, or a
dynamically linked linux binary built on a somewhat older box - that
binary of yours requires a relatively current set of linux shared libraries
(which _is_ in ports, but is not the default for linux-compat yet).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: NO
Scanned log, also have errors for:
ed2k_gui in free(): warning: junk pointer, too high to make
sense
** CRITICAL **: file search_data.c: line 251
(searchlist_destroy): assertion `idxpos>=0' failed.
Logged In: YES
user_id=583691
I think this problem has to do with a different behaviour of the
glib GIOChannel callback on FreeBSD and linux. Don't ask
me what exactly the problem is, I think there might still be
some commented out code in pipe.c in the callback.
Also, I don't have FreeBSD, so I can't really debug this
myself. I am afraid you'll have to do this yourself.
Alternatively, in main.c, main(), remove the call to pipe_create
() and pipe_unlink(). The pipe is just an extra, it's not
necessary at all.
The junk pointer error msg I can't make sense of either. where
does that msg come from?
The last one (searchlist_destroy) I wouldn't worry about.
Sorry I can't be more helpful.
Cheers
-Tim
PS: I don't think that the fact whether a core is running or not
matters in this case. Does it? I wouldn't think so.
Logged In: YES
user_id=583691
I think this problem has to do with a different behaviour of the
glib GIOChannel callback on FreeBSD and linux. Don't ask
me what exactly the problem is, I think there might still be
some commented out code in pipe.c in the callback.
Also, I don't have FreeBSD, so I can't really debug this
myself. I am afraid you'll have to do this yourself.
Alternatively, in main.c, main(), remove the call to pipe_create
() and pipe_unlink(). The pipe is just an extra, it's not
necessary at all.
The junk pointer error msg I can't make sense of either. where
does that msg come from?
The last one (searchlist_destroy) I wouldn't worry about.
Sorry I can't be more helpful.
Cheers
-Tim
PS: I don't think that the fact whether a core is running or not
matters in this case. Does it? I wouldn't think so.
Logged In: NO
Hi Tim,
I'm having the same problem with FreeBSD 4.7 and ed2k_guy 0.3 und 0.4. version 0.2 works fine.
I followed your advice and commented out the pipe_create and pipe_unlink calls. It works now, and I'm happily using the 0.4.0 Version built on Jan 6 :-)
Maybe you could make this a configure switch?
Logged In: YES
user_id=583691
I have just checked some code into CVS that spits out a lot of
debugging information in case it has been compiled on
FreeBSD. It will also disable the pipe after 1000 re-creates.
If you are using FreeBSD, please be so kind and compile the
latest CVS version, and then send me the output you get on
the terminal when you start the GUI. This would help me a lot
in tracking down this bug. I think it is better to fix this than to
switch this feature off.
Thanks! :-)
Cheers
-Tim
Logged In: YES
user_id=583691
I think I've solved this.
The solution appears to be to open the pipe in blocking mode,
instead of non-blocking mode (O_RDONLY, instead of
(O_RDONLY | O_NONBLOCK)).
I'll commit this to CVS, so it will be in the next source code
release.
At least this solution works on the sourceforge compile-farm
(freebsd-4.7-stable IIRC).
fixed in CVS.
Logged In: YES
user_id=907399
This one needs a better fix. With 0.6.0 (and current CVS) and FreeBSD
4.9-RELEASE, ed2k_gui hangs on this pipe after startup before even
opening the gui. Not creating it in the first place works around this, but
it's obviously not a fix. Anyway, this happens regardless of
O_NONBLOCK or not.
Logged In: YES
user_id=583691
I'm re-opening this then.
This used to be fixed at some point with gtk/glib-1.2, but it
seems that it broke again on FreeBSD when we did the port to
gtk/glib-2.x.
Truth is though that this is unlikely to get fixed until some
FreeBSD person sits down with a cup of tea and some biscuits
and tries to fix it, as I don't have access to a FreeBSD system
(the sourceforge compile farm one is up ca. 1 hour per month,
and then completely unresponsive, and thus not really usable
for debugging stuff like this unfortunately).
-Tim
pipe.c that hopefully fixes things
Logged In: YES
user_id=583691
Today is your lucky day - the sourceforge FreeBSD compile
farm hosts was up, and even usable, so with a bit of luck I
might have fixed the problem.
Please try the attached pipe.c file instead of the current one,
and report whether things work then on FreeBSD.
Cheers
-Tim
Logged In: YES
user_id=907399
Wow, that was quick and it works, too! (Actually I am a FreeBSD
person and I was just going to sit down with the tea & biscuits right
now).
Thanks a book! :-)
Logged In: YES
user_id=583691
This should be fixed in v0.6.1
Now if someone familiar with the FreeBSD ports system could
get the ed2k_gui maintainer to ditch v0.5.0 and build a new
version....
Logged In: NO
lioux is probably both busy or has been reluctant to upgrade the port
due to the reappearance of this bug. I'll make sure the port gets
updated to 0.6.1 once it's released.
Logged In: YES
user_id=907399
Whoops, didn't realise you put out a new release that quickly. :)
I can't commit right away because lioux is the port-maintainer, but I've
tried and spare him the donkey(heh)work:
http://www.freebsd.org/cgi/query-pr.cgi?pr=59278
Cheers.
Logged In: YES
user_id=583691
Lofi: Thanks :-)
I didn't mean to be rude in case it came across that way. Just
wrote him several e-mails over the past couple of months and
never got a reply.
Anyway, I hope this gets resolved now.
The core would need to be updated as well, btw.
Cheers
-Tim
Logged In: YES
user_id=907399
Unfortunately, the core cannot be updated in ports because 0.51.2 has
issues with FreeBSD's linux-runtime-compat and crashes with 'Bad
system call' shortly after startup.
Logged In: YES
user_id=583691
oh, I didn't know that. What about 0.50.1? Same thing?
In any case, I'll try to get someone to build a native x86
FreeBSD version, or do it myself if I manage to free a
partition somewhere. No promises though.
Might it be related to the fact that it's statically linked?
Here's a dynamically linked version in case you want to try
that (linux/x86):
http://ed2k-gtk-gui.sf.net/temp/overnet0.51.2-tim
Anyway, I'll be gone until next Wednesday. Then I'll see what
I can do.
Cheers
-Tim
Logged In: YES
user_id=907399
0.50.1 is the current version in ports, it works fine. Your dynamically
linked core works fine, too!
However, we'd probably indeed need either a native binary, or a
dynamically linked linux binary built on a somewhat older box - that
binary of yours requires a relatively current set of linux shared libraries
(which _is_ in ports, but is not the default for linux-compat yet).