Re: cvsup broken on amd64?
cvsup is a port, so you would need to install that to have cvsup. csup and cvsup are totally different code bases in different languages. (csup is C and cvsup is Modula-3.) You probably want to install cvsup as a package as installing the port also requires building all of the Modula-3 compiler, not a small install. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@gmail.com I just checked, again, directory /usr/share/examples/cvsup and was directed to the Handbook section on CVSup, A6. But I checked and found nothing with modula in ports; later used the search on modula-3 and found ezm3. I ran make missing and make all-depends-list in net/cvsup directory and got no dependencies in either case. No Modula-3? Anyway, from what I read, csup is better, and I think I can use the same supfile and same server that I would use for cvsup? I've heard of Modula-2 and 3, but those languages were never widely used as far as I know. Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Wed, Oct 05, 2011 at 03:21:45PM -0700, David O'Brien wrote:
On Fri, Sep 09, 2011 at 06:00:02PM +0300, Kostik Belousov wrote:
--- libs/m3core/src/thread/POSIX/ThreadPosix.m3.orig2011-09-09
17:58:12.867431639 +0300
+++ libs/m3core/src/thread/POSIX/ThreadPosix.m3 2011-09-09
17:58:30.380428486 +0300
@@ -180,7 +180,7 @@
pausedThreads : T;
selected_interval:= UTime{0, 100 * 1000};
- defaultStackSize := 3000;
+ defaultStackSize := 1;
This might not be a large enough value (depending on the unit of measure).
I synced tzdata+tzcode at $WORK and we found the amount of stack used by
tzload() alone is now quite large -- 41k on ARM.
Please see r225677.
pgpjpUkg0NdSp.pgp
Description: PGP signature
Re: cvsup broken on amd64?
On 10/06/2011 01:41, Thomas Mueller wrote: Anyway, from what I read, csup is better, and I think I can use the same supfile and same server that I would use for cvsup? Yes. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Hi all, I've committed this to -head. I'd appreciate it if csup users would give this a thorough testing and report back to the list with results. I won't submit this as a merge candidate this to stable/9 without a whole lot of testing. :) Thanks, Adrian I am now in 9.0-BETA2 amd64 and looking to update via source. There is /usr/bin/csup but no cvsup. Can I safely use csup on tag RELENG_9 to update, or is that broken? Does this csup come under the cvsup bug in this thread? Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Wed, Oct 5, 2011 at 1:34 AM, Thomas Mueller mueller6...@bellsouth.net wrote: Hi all, I've committed this to -head. I'd appreciate it if csup users would give this a thorough testing and report back to the list with results. I won't submit this as a merge candidate this to stable/9 without a whole lot of testing. :) Thanks, Adrian I am now in 9.0-BETA2 amd64 and looking to update via source. There is /usr/bin/csup but no cvsup. Can I safely use csup on tag RELENG_9 to update, or is that broken? Does this csup come under the cvsup bug in this thread? cvsup is a port, so you would need to install that to have cvsup. csup and cvsup are totally different code bases in different languages. (csup is C and cvsup is Modula-3.) You probably want to install cvsup as a package as installing the port also requires building all of the Modula-3 compiler, not a small install. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Fri, Sep 09, 2011 at 06:00:02PM +0300, Kostik Belousov wrote:
--- libs/m3core/src/thread/POSIX/ThreadPosix.m3.orig 2011-09-09
17:58:12.867431639 +0300
+++ libs/m3core/src/thread/POSIX/ThreadPosix.m3 2011-09-09
17:58:30.380428486 +0300
@@ -180,7 +180,7 @@
pausedThreads : T;
selected_interval:= UTime{0, 100 * 1000};
- defaultStackSize := 3000;
+ defaultStackSize := 1;
This might not be a large enough value (depending on the unit of measure).
I synced tzdata+tzcode at $WORK and we found the amount of stack used by
tzload() alone is now quite large -- 41k on ARM.
--
-- David (obr...@freebsd.org)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Tue, Oct 4, 2011 at 2:19 AM, Adrian Chadd adr...@freebsd.org wrote: On 4 October 2011 05:53, Maxime Henrion m...@freebsd.org wrote: Great, that's a relief. I knew the pthread library was free to wake a thread up even if it hadn't been signaled, which is why one always has to call pthread_cond_wait() inside of a while() loop checking for the condition, but wasn't sure about that particular scenario, so I'm glad to hear a confirmation. Thanks! So shall I commit your change, if someone hasn't already? That would be great (I cannot commit it myself anymore). If you could also fix the misleading comment I've been talking about (s/lister thread/detailer thread/), it would be perfect. Thanks, Maxime ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Hi all, I've committed this to -head. I'd appreciate it if csup users would give this a thorough testing and report back to the list with results. I won't submit this as a merge candidate this to stable/9 without a whole lot of testing. :) Thanks, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Mon, Sep 19, 2011 at 8:26 AM, Adrian Chadd adr...@freebsd.org wrote:
2011/9/19 Alexander Zagrebin al...@visp.ru:
I've tried this patch. Now csup hangs before handling fixups.
So there is no message Applying fixups... at all.
Wow. Hm. Where's the author when one needs them..
Well that's quite a strange coincidence. I haven't read current@ in
ages and now I just stumble upon this. :-)
It's been a long time since I've been looking at this code but the
patch from the original PR seems /nearly/ correct, while the one from
adrian@ is definitely incorrect. But to be honest, this part of the
CVSup protocol is a lot more twisted than it would seem, plus a
comment of mine was definitely misleading (it should say that the
detailer thread will hang, not the lister one). Here are some
explanations that should help clarify things.
When the updater thread encountered a problem in updating a file (MD5
checksum doesn't match), it will send a fixup request to the
detailer thread. The detailer thread then sends this request to the
CVSup server, which, finally, sends the whole file for the _updater_
thread to receive. So what's happening at this position in the code is
that the updater thread finished processing all the normal updates,
and thus knows there won't be any more fixup requests (fixups
themselves can't generate other fixups). This is why it closes the
writing end of the fixups queue, to wake up the detailer thread which
will notice the closed state and the absence of fixups in the queue,
and will thus terminate. So we _have_ to call fixups_close() here, or
the detailer thread will block indefinitely in fixups_get() when an
error happened.
Knowing all that, what's happening seems quite clear. If
fixups_close() is called while there was still fixup requests pending,
those should be processed by the detailer thread before it returns.
Subsequent fixups_get() call should continue returning pending items,
until there are no more entries in the queue _and_ the queue is
closed.
So, line 144 in fixups.c (in fixups_get()):
if (f-closed) {
should actually be:
if (f-closed f-size == 0) {
The fact that this could even happen smells a bit weird to me though;
it means the detailer thread didn't get a chance to run between some
item was added to the queue (fixups_put() signals the detailer thread
via pthread_cond_signal()), and that it only runs now that the updater
queue has been closed. I wouldn't go as far as saying this is a bug,
but is it even valid for the pthread library to coalesce two
pthread_cond_signal() calls into one when the thread didn't get to run
since the first call was made? If so, then the above fix is perfectly
valid. If not, there is a deeper bug in the threading library, or in
the CVS mode code which I didn't write (but that seems far-fetched).
It would be great to fix my misleading comment too by the way :-)
I hope this helps.
Cheers,
Maxime
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Mon, Oct 03, 2011 at 06:15:41PM +0200, Maxime Henrion wrote:
Knowing all that, what's happening seems quite clear. If
fixups_close() is called while there was still fixup requests pending,
those should be processed by the detailer thread before it returns.
Subsequent fixups_get() call should continue returning pending items,
until there are no more entries in the queue _and_ the queue is
closed.
So, line 144 in fixups.c (in fixups_get()):
if (f-closed) {
should actually be:
if (f-closed f-size == 0) {
That looks sensible.
The fact that this could even happen smells a bit weird to me though;
it means the detailer thread didn't get a chance to run between some
item was added to the queue (fixups_put() signals the detailer thread
via pthread_cond_signal()), and that it only runs now that the updater
queue has been closed. I wouldn't go as far as saying this is a bug,
but is it even valid for the pthread library to coalesce two
pthread_cond_signal() calls into one when the thread didn't get to run
since the first call was made? If so, then the above fix is perfectly
valid. If not, there is a deeper bug in the threading library, or in
the CVS mode code which I didn't write (but that seems far-fetched).
The pthread library is free to coalesce pthread_cond_signal() calls
like that. This is because a thread awakened by pthread_cond_signal()
(or any other event) is not guaranteed to start running immediately and
pthread_cond_signal() does nothing if there is no thread to wake up.
If there is no second CPU core available to run the detailer thread, it
is more efficient to have the updater thread do some more work before
incurring a context switch.
--
Jilles Tjoelker
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Mon, Oct 3, 2011 at 11:30 PM, Jilles Tjoelker jil...@stack.nl wrote:
On Mon, Oct 03, 2011 at 06:15:41PM +0200, Maxime Henrion wrote:
Knowing all that, what's happening seems quite clear. If
fixups_close() is called while there was still fixup requests pending,
those should be processed by the detailer thread before it returns.
Subsequent fixups_get() call should continue returning pending items,
until there are no more entries in the queue _and_ the queue is
closed.
So, line 144 in fixups.c (in fixups_get()):
if (f-closed) {
should actually be:
if (f-closed f-size == 0) {
That looks sensible.
The fact that this could even happen smells a bit weird to me though;
it means the detailer thread didn't get a chance to run between some
item was added to the queue (fixups_put() signals the detailer thread
via pthread_cond_signal()), and that it only runs now that the updater
queue has been closed. I wouldn't go as far as saying this is a bug,
but is it even valid for the pthread library to coalesce two
pthread_cond_signal() calls into one when the thread didn't get to run
since the first call was made? If so, then the above fix is perfectly
valid. If not, there is a deeper bug in the threading library, or in
the CVS mode code which I didn't write (but that seems far-fetched).
The pthread library is free to coalesce pthread_cond_signal() calls
like that. This is because a thread awakened by pthread_cond_signal()
(or any other event) is not guaranteed to start running immediately and
pthread_cond_signal() does nothing if there is no thread to wake up.
Great, that's a relief. I knew the pthread library was free to wake a
thread up even if it hadn't been signaled, which is why one always has
to call pthread_cond_wait() inside of a while() loop checking for the
condition, but wasn't sure about that particular scenario, so I'm glad
to hear a confirmation. Thanks!
Cheers,
Maxime
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On 4 October 2011 05:53, Maxime Henrion m...@freebsd.org wrote: Great, that's a relief. I knew the pthread library was free to wake a thread up even if it hadn't been signaled, which is why one always has to call pthread_cond_wait() inside of a while() loop checking for the condition, but wasn't sure about that particular scenario, so I'm glad to hear a confirmation. Thanks! So shall I commit your change, if someone hasn't already? Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
2011/9/19 Alexander Zagrebin al...@visp.ru: I've tried this patch. Now csup hangs before handling fixups. So there is no message Applying fixups... at all. Wow. Hm. Where's the author when one needs them.. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Hi,
So I've taken a look at the csup source.
The problem here is the updater thread setting the closed state
(fixups_closed()) before calling updater_batch() again to handle
fixups.
Checking for size != 0 at that point may not be valid at the list size
may actually be 0 for a short period of time.
What about this patch:
Index: updater.c
===
--- updater.c (revision 224905)
+++ updater.c (working copy)
@@ -240,9 +240,9 @@
* Make sure to close the fixups even in case of an error,
* so that the lister thread doesn't block indefinitely.
*/
- fixups_close(up-config-fixups);
if (!error)
error = updater_batch(up, 1);
+ fixups_close(up-config-fixups);
switch (error) {
case UPDATER_ERR_PROTO:
xasprintf(args-errmsg, Updater failed: Protocol error);
Oliver, would you please try that?
Thanks,
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Adrian Chadd adr...@freebsd.org wrote: So I've taken a look at the csup source. [...] What about this patch: [...] Oliver, would you please try that? I have a problem with cvsup, not csup - Alexander mentioned a csup problem. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Sun, Sep 18, 2011 at 12:22:53PM +0200, Oliver Lehmann wrote: Adrian Chadd adr...@freebsd.org wrote: So I've taken a look at the csup source. [...] What about this patch: [...] Oliver, would you please try that? I have a problem with cvsup, not csup - Alexander mentioned a csup problem. Did you saw the message with the patch for tzcode I mailed to you ? pgpxG7jeO8J6E.pgp Description: PGP signature
Re: cvsup broken on amd64?
Ah, you're the one with the csup problem.
Would you mind trying csup again, and if it doesn't work, try this patch:
Index: updater.c
===
--- updater.c (revision 224905)
+++ updater.c (working copy)
@@ -240,9 +240,9 @@
* Make sure to close the fixups even in case of an error,
* so that the lister thread doesn't block indefinitely.
*/
- fixups_close(up-config-fixups);
if (!error)
error = updater_batch(up, 1);
+ fixups_close(up-config-fixups);
switch (error) {
case UPDATER_ERR_PROTO:
xasprintf(args-errmsg, Updater failed: Protocol error);
There's a PR open now (154954) but the patch may be wrong.
thanks,
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Kostik Belousov kostik...@gmail.com wrote: Did you saw the message with the patch for tzcode I mailed to you ? Mmmh... no didn't reached my mailbox - can you resend it please? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Sun, Sep 18, 2011 at 02:46:24PM +0200, Oliver Lehmann wrote: Kostik Belousov kostik...@gmail.com wrote: Did you saw the message with the patch for tzcode I mailed to you ? Mmmh... no didn't reached my mailbox - can you resend it please? See the Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW) thread on the current@, where you are explicitely Cc:ed. I posted updated patch a minute ago. pgpbmqafpbDxl.pgp Description: PGP signature
RE: cvsup broken on amd64?
Hi!
So I've taken a look at the csup source.
The problem here is the updater thread setting the closed state
(fixups_closed()) before calling updater_batch() again to handle
fixups.
Checking for size != 0 at that point may not be valid at the list size
may actually be 0 for a short period of time.
What about this patch:
Index: updater.c
===
--- updater.c (revision 224905)
+++ updater.c (working copy)
@@ -240,9 +240,9 @@
* Make sure to close the fixups even in case of an error,
* so that the lister thread doesn't block indefinitely.
*/
- fixups_close(up-config-fixups);
if (!error)
error = updater_batch(up, 1);
+ fixups_close(up-config-fixups);
switch (error) {
case UPDATER_ERR_PROTO:
xasprintf(args-errmsg, Updater failed:
Protocol error);
I've tried this patch. Now csup hangs before handling fixups.
So there is no message Applying fixups... at all.
--
Alexander Zagrebin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Pester the maintainer? Adrian 2011/9/15 Alexander Zagrebin al...@visp.ru: I'm also using cvsup again, due to a problem I had with csup back in February 2011 http://www.mail-archive.com/freebsd-stable@freebsd.org/msg114 813.html . I didn't open a PR; I was under some time pressure and cvsup worked. There is a solution of the csup problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/154954 I've opened this PR, but nobody has paid to it attentions. :( -- Alexander Zagrebin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Wed, Sep 14, 2011 at 11:19 PM, Adrian Chadd adr...@freebsd.org wrote: Pester the maintainer? The maintainer is alumni. -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: cvsup broken on amd64?
Pester the maintainer? I've thought that if an opened PR exists, then it have to be reviewed sooner or later... -- Alexander Zagrebin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
on 15/09/2011 12:16 Alexander Zagrebin said the following: Pester the maintainer? I've thought that if an opened PR exists, then it have to be reviewed sooner or later... Usually rather quite later than sooner. There are about 5000 non-ports PRs and there are only a few dozen active developers. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Usually rather quite later than sooner. A perfect opportunity for src committers to dive in and make a difference :-) mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On 15 September 2011 18:05, Mark Linimon lini...@lonesome.com wrote: Usually rather quite later than sooner. A perfect opportunity for src committers to dive in and make a difference :-) I hate you. :) Ok. Some third person test/verify that this patch (a) does what it's supposed to do, and (b) is correct, and I'll commit it. (blah, what am I signing myself up for..) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Thu, Sep 15, 2011 at 8:19 AM, Adrian Chadd adr...@freebsd.org wrote: On 15 September 2011 18:05, Mark Linimon lini...@lonesome.com wrote: Usually rather quite later than sooner. A perfect opportunity for src committers to dive in and make a difference :-) I hate you. :) Ok. Some third person test/verify that this patch (a) does what it's supposed to do, and (b) is correct, and I'll commit it. (blah, what am I signing myself up for..) Based on the ticket and the patch, I think this is the right procedure for verifying the patch. Please verify that the case below repros the issue seen by the end-user before applying the patch though :). Thanks, -Garrett supdir=$(mktemp -d /tmp/sup.XX) # Supfile follows. Change cvsup host as necessary.. cat $supdir/supfile EOF *default host=cvsup10.FreeBSD.org *default base=$supdir *default prefix=$supdir/checkout *default release=cvs *default delete use-rel-suffix *default compress src-all EOF # Get the sources csup $supdir/supfile # Empty out the files for i in $(find $supdir/supfile/sys -name '*.[ch]'); do : $i done # This should fail, requiring multiple tries. csup $supdir/supfile # Clean up rm -Rf $supdir ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Thu, Sep 15, 2011 at 9:30 AM, Garrett Cooper yaneg...@gmail.com wrote: On Thu, Sep 15, 2011 at 8:19 AM, Adrian Chadd adr...@freebsd.org wrote: On 15 September 2011 18:05, Mark Linimon lini...@lonesome.com wrote: Usually rather quite later than sooner. A perfect opportunity for src committers to dive in and make a difference :-) I hate you. :) Ok. Some third person test/verify that this patch (a) does what it's supposed to do, and (b) is correct, and I'll commit it. (blah, what am I signing myself up for..) Based on the ticket and the patch, I think this is the right procedure for verifying the patch. Please verify that the case below repros the issue seen by the end-user before applying the patch though :). Thanks, -Garrett supdir=$(mktemp -d /tmp/sup.XX) # Supfile follows. Change cvsup host as necessary.. cat $supdir/supfile EOF *default host=cvsup10.FreeBSD.org *default base=$supdir *default prefix=$supdir/checkout *default release=cvs *default delete use-rel-suffix *default compress src-all EOF # Get the sources csup $supdir/supfile # Empty out the files for i in $(find $supdir/supfile/sys -name '*.[ch]'); do This should be $supdir/checkout/sys . Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: cvsup broken on amd64?
I'm also using cvsup again, due to a problem I had with csup back in February 2011 http://www.mail-archive.com/freebsd-stable@freebsd.org/msg114 813.html . I didn't open a PR; I was under some time pressure and cvsup worked. There is a solution of the csup problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/154954 I've opened this PR, but nobody has paid to it attentions. :( -- Alexander Zagrebin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Fri, 09 Sep 2011 13:47:37 +0200 Oliver Lehmann lehm...@ans-netz.de wrote: Kostik Belousov kostik...@gmail.com wrote: For start, you should provide the information what exactly is the instruction that caused the fault. Show the disassembly from gdb for the function that caused the fault. Ok, I'm trying. I recompiled cvsup for purpose with -DSTATIC How do I continue from the gdb output below to help? nudel# gdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd. (gdb) file ./client/FBSD_AMD64/cvsup Reading symbols from ./client/FBSD_AMD64/cvsup...done. (gdb) exec-file ./client/FBSD_AMD64/cvsup (gdb) set args -g /usr/share/examples/cvsup/9-supfile (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () [snip] Ah yes, I've seen this before. I don't know whether it's till the case, but my fix at the time (about 1 year ago) was to delete /usr/share/zoneinfo/UTC. I don't know whether that's even still installed. I know, it's just a work around and not a real fix. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Mike Tancsa m...@sentex.net wrote: Just curious as to why you need cvsup and not instead use csup that is in the base ? I got used to it in the past 12 years? But this is not realy the question. If it is BROKEN it should be marked as BROKEN or there should be a statement that it will not work with FreeBSD 9 on at least amd64 or we will have other users complaining about the same at least when 9.0 RELEASE is out - right? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On 9 September 2011 06:33, Oliver Lehmann lehm...@ans-netz.de wrote: Mike Tancsa m...@sentex.net wrote: Just curious as to why you need cvsup and not instead use csup that is in the base ? I got used to it in the past 12 years? But this is not realy the question. If it is BROKEN it should be marked as BROKEN or there should be a statement that it will not work with FreeBSD 9 on at least amd64 or we will have other users complaining about the same at least when 9.0 RELEASE is out - right? The cvsup port is normally used now only for cvsupd, for which there is no csupd analog. As far as I know, and perhaps mux (CC'd) could confirm every feature present in cvsup is present in csup-- and it's a fair amount faster too. Of course, cvsup could probably do with fixing, but for now csup is literally a drop-in replacement; it'll read all your supfiles too. Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Chris Rees cr...@freebsd.org wrote: On 9 September 2011 06:33, Oliver Lehmann lehm...@ans-netz.de wrote: I got used to it in the past 12 years? But this is not realy the question. If it is BROKEN it should be marked as BROKEN or there should be a statement that it will not work with FreeBSD 9 on at least amd64 or we will have other users complaining about the same at least when 9.0 RELEASE is out - right? The cvsup port is normally used now only for cvsupd, for which there is no csupd analog. As far as I know, and perhaps mux (CC'd) could confirm every feature present in cvsup is present in csup-- and it's a fair amount faster too. Ok, but this again is not the point of my email ;) This is not about just me. I know how to help me in that case. I want to prevent users facing the same problem and writing mails like my initial mail. I'm quiet sure that there are numerous users out there still using cvsup as client so they will start like me with cvsup on ther new instaled system. It would be better if they just would not be able to install cvsup if it will not run and we don't want it to run. I was also curious if it is only me where it fails on amd64 or if it is because it was compiled on an Atom 330 with some amd64 flags determined by the system which does not fit the Atom 330 (gcc 4.2 is older than the CPU design). With other words: If the support for cvsup on amd64 is dropped, it has to be marked as BROKEN/IGNORE/whatever. Otherwise it need to get fixed for 9.0? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Fri, Sep 09, 2011 at 11:30:46AM +0200, Oliver Lehmann wrote: Chris Rees cr...@freebsd.org wrote: On 9 September 2011 06:33, Oliver Lehmann lehm...@ans-netz.de wrote: I got used to it in the past 12 years? But this is not realy the question. If it is BROKEN it should be marked as BROKEN or there should be a statement that it will not work with FreeBSD 9 on at least amd64 or we will have other users complaining about the same at least when 9.0 RELEASE is out - right? The cvsup port is normally used now only for cvsupd, for which there is no csupd analog. As far as I know, and perhaps mux (CC'd) could confirm every feature present in cvsup is present in csup-- and it's a fair amount faster too. Ok, but this again is not the point of my email ;) This is not about just me. I know how to help me in that case. I want to prevent users facing the same problem and writing mails like my initial mail. I'm quiet sure that there are numerous users out there still using cvsup as client so they will start like me with cvsup on ther new instaled system. It would be better if they just would not be able to install cvsup if it will not run and we don't want it to run. I was also curious if it is only me where it fails on amd64 or if it is because it was compiled on an Atom 330 with some amd64 flags determined by the system which does not fit the Atom 330 (gcc 4.2 is older than the CPU design). With other words: If the support for cvsup on amd64 is dropped, it has to be marked as BROKEN/IGNORE/whatever. Otherwise it need to get fixed for 9.0? For start, you should provide the information what exactly is the instruction that caused the fault. Show the disassembly from gdb for the function that caused the fault. pgpNzY8kGtDDW.pgp Description: PGP signature
Re: cvsup broken on amd64?
Kostik Belousov kostik...@gmail.com wrote: For start, you should provide the information what exactly is the instruction that caused the fault. Show the disassembly from gdb for the function that caused the fault. Ok, I'm trying. I recompiled cvsup for purpose with -DSTATIC How do I continue from the gdb output below to help? nudel# gdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd. (gdb) file ./client/FBSD_AMD64/cvsup Reading symbols from ./client/FBSD_AMD64/cvsup...done. (gdb) exec-file ./client/FBSD_AMD64/cvsup (gdb) set args -g /usr/share/examples/cvsup/9-supfile (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () (gdb) bt #0 0x004d24c6 in tzload () #1 0x004d1f89 in tzparse () #2 0x004d2c27 in tzload () #3 0x004d2e36 in gmtload () #4 0x004eac15 in _once () #5 0x004d1c8b in gmtsub () #6 0x004d33e9 in gmtime () #7 0x004a3d4a in Date__FromTime (M3_CtKayy_t=1314794791, M3_Ab1PrR_z=0x7ed538, M3_D5xROs__result=0x934c08) at DateBsd.m3:31 #8 0x004387d7 in RCSDate__FromTime (M3_CtKayy_t=1314794791) at RCSDate.m3:54 #9 0x004467ba in RCSFile__Import (M3_Bd56fi_p=0xa74040, M3_Bd56fi_revNum=0x9f4828, M3_Bd56fi_author=0x763020, M3_Bd56fi_state=0x763040, M3_AcxOUs_logLines=12) at RCSFile.m3:413 #10 0x004077de in CheckoutUpdater__Update (M3_CTVCUv_self=0x9f49e0, M3_CzVV2w_sfr=0x7ff2e0, M3_Bd56fi_name=0x9f47e8, M3_AicXUJ_toAttic=0 '\0', M3_DsoVVS_proto=0x7f74a8, M3_AeHwgK_trace=0x7f8710, M3_EkTcCb_protoRd=0x9c98f8, M3_BxxOH1_wr=0x9f4ef8, M3_AQMw24_status=0x935f48) at CheckoutUpdater.m3:111 #11 0x00416ab4 in Updater__UpdateFile (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_Bd56fi_name=0x9f47e8, M3_AicXUJ_toAttic=0 '\0', M3_DMoNGc_fup=0x9f49e0, M3_AicXUJ_isFixup=0 '\0') at Updater.m3:641 #12 0x004155ce in Updater__UpdateCollection (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:458 #13 0x00412baf in Updater__UpdateBatch (M3_DBUV6k_self=0x7fee38, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:151 #14 0x0041268a in Updater__Apply (M3_DBUV6k_self=0x7fee38) at Updater.m3:90 #15 0x0049d290 in ThreadPosix__DetermineContext (M3_AJWxb1_oldSP=0x7edfd0) at ThreadPosix.m3:1127 #16 0x0048d34d in RTCollector__LongAlloc (M3_Cwb5VA_dataSize=4337239, M3_Cwb5VA_dataAlignment=8577024, M3_AOtCKl_currentPtr=0x7f8, M3_AOtCKl_currentBoundary=0x76c8f8, M3_CCsHD8_currentPage=0x0, M3_CCsHD8_stack=0x0, M3_D8qd0n_allocMode=48 '0', M3_AicXUJ_pure=16 '\020') at RTCollector.m3:1530 #17 0x7fffc3c8 in ?? () #18 0x7fffd930 in ?? () #19 0x7fffda10 in ?? () #20 0x7fffd9f0 in ?? () #21 0x in ?? () #22 0x in ?? () #23 0x1fa0037f in ?? () #24 0x in ?? () #25 0x007f76c0 in ?? () #26 0x007f76c0 in ?? () #27 0x00492699 in RTMisc__Copy (M3_AJWxb1_src=Error accessing memory address 0xfffb: Bad address. ) at RTMisc.m3:19 Previous frame inner to this frame (corrupt stack?) (gdb) RTMisc.m3:19 is PROCEDURE Copy (src, dest: ADDRESS; len: INTEGER) = BEGIN EVAL Cstring.memcpy (dest, src, len); END Copy; ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Fri, Sep 09, 2011 at 01:47:37PM +0200, Oliver Lehmann wrote: Kostik Belousov kostik...@gmail.com wrote: For start, you should provide the information what exactly is the instruction that caused the fault. Show the disassembly from gdb for the function that caused the fault. Ok, I'm trying. I recompiled cvsup for purpose with -DSTATIC How do I continue from the gdb output below to help? I do not know, I was curious about 'illegal instruction' signal, which would indicate a problem in the compilation environment. Now you get segmentation violation, that is usually caused by a bug in the program itself. nudel# gdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd. (gdb) file ./client/FBSD_AMD64/cvsup Reading symbols from ./client/FBSD_AMD64/cvsup...done. (gdb) exec-file ./client/FBSD_AMD64/cvsup (gdb) set args -g /usr/share/examples/cvsup/9-supfile (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () (gdb) bt #0 0x004d24c6 in tzload () #1 0x004d1f89 in tzparse () #2 0x004d2c27 in tzload () #3 0x004d2e36 in gmtload () #4 0x004eac15 in _once () #5 0x004d1c8b in gmtsub () #6 0x004d33e9 in gmtime () #7 0x004a3d4a in Date__FromTime (M3_CtKayy_t=1314794791, M3_Ab1PrR_z=0x7ed538, M3_D5xROs__result=0x934c08) at DateBsd.m3:31 #8 0x004387d7 in RCSDate__FromTime (M3_CtKayy_t=1314794791) at RCSDate.m3:54 #9 0x004467ba in RCSFile__Import (M3_Bd56fi_p=0xa74040, M3_Bd56fi_revNum=0x9f4828, M3_Bd56fi_author=0x763020, M3_Bd56fi_state=0x763040, M3_AcxOUs_logLines=12) at RCSFile.m3:413 #10 0x004077de in CheckoutUpdater__Update (M3_CTVCUv_self=0x9f49e0, M3_CzVV2w_sfr=0x7ff2e0, M3_Bd56fi_name=0x9f47e8, M3_AicXUJ_toAttic=0 '\0', M3_DsoVVS_proto=0x7f74a8, M3_AeHwgK_trace=0x7f8710, M3_EkTcCb_protoRd=0x9c98f8, M3_BxxOH1_wr=0x9f4ef8, M3_AQMw24_status=0x935f48) at CheckoutUpdater.m3:111 #11 0x00416ab4 in Updater__UpdateFile (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_Bd56fi_name=0x9f47e8, M3_AicXUJ_toAttic=0 '\0', M3_DMoNGc_fup=0x9f49e0, M3_AicXUJ_isFixup=0 '\0') at Updater.m3:641 #12 0x004155ce in Updater__UpdateCollection (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:458 #13 0x00412baf in Updater__UpdateBatch (M3_DBUV6k_self=0x7fee38, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:151 #14 0x0041268a in Updater__Apply (M3_DBUV6k_self=0x7fee38) at Updater.m3:90 #15 0x0049d290 in ThreadPosix__DetermineContext (M3_AJWxb1_oldSP=0x7edfd0) at ThreadPosix.m3:1127 #16 0x0048d34d in RTCollector__LongAlloc (M3_Cwb5VA_dataSize=4337239, M3_Cwb5VA_dataAlignment=8577024, M3_AOtCKl_currentPtr=0x7f8, M3_AOtCKl_currentBoundary=0x76c8f8, M3_CCsHD8_currentPage=0x0, M3_CCsHD8_stack=0x0, M3_D8qd0n_allocMode=48 '0', M3_AicXUJ_pure=16 '\020') at RTCollector.m3:1530 #17 0x7fffc3c8 in ?? () #18 0x7fffd930 in ?? () #19 0x7fffda10 in ?? () #20 0x7fffd9f0 in ?? () #21 0x in ?? () #22 0x in ?? () #23 0x1fa0037f in ?? () #24 0x in ?? () #25 0x007f76c0 in ?? () #26 0x007f76c0 in ?? () #27 0x00492699 in RTMisc__Copy (M3_AJWxb1_src=Error accessing memory address 0xfffb: Bad address. ) at RTMisc.m3:19 Previous frame inner to this frame (corrupt stack?) (gdb) RTMisc.m3:19 is PROCEDURE Copy (src, dest: ADDRESS; len: INTEGER) = BEGIN EVAL Cstring.memcpy (dest, src, len); END Copy; pgp2QJtgOP9FU.pgp Description: PGP signature
Re: cvsup broken on amd64?
On 09/09/11 01:33, Oliver Lehmann wrote: Mike Tancsam...@sentex.net wrote: Just curious as to why you need cvsup and not instead use csup that is in the base ? I got used to it in the past 12 years? But this is not realy the question. If it is BROKEN it should be marked as BROKEN or there should be a statement that it will not work with FreeBSD 9 on at least amd64 or we will have other users complaining about the same at least when 9.0 RELEASE is out - right? I'm also using cvsup again, due to a problem I had with csup back in February 2011 http://www.mail-archive.com/freebsd-stable@freebsd.org/msg114813.html . I didn't open a PR; I was under some time pressure and cvsup worked. - Richard -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Kostik Belousov kostik...@gmail.com wrote: I do not know, I was curious about 'illegal instruction' signal, which would indicate a problem in the compilation environment. Now you get segmentation violation, that is usually caused by a bug in the program itself. running it outside gdb still results in an 'illegal instruction' error. Why it gets to segmentation violation inside gdb I just don't know. nudel# ./client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Illegal instruction (core dumped) nudel# gdb ./client/FBSD_AMD64/cvsup cvsup.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Core was generated by `cvsup'. Program terminated with signal 4, Illegal instruction. #0 0x004d24c6 in tzload () (gdb) bt #0 0x004d24c6 in tzload () #1 0x004d1f89 in tzparse () #2 0x004d2c27 in tzload () #3 0x004d2e36 in gmtload () #4 0x004eac15 in _once () #5 0x004d1c8b in gmtsub () #6 0x004d33e9 in gmtime () #7 0x004a3d4a in Date__FromTime (M3_CtKayy_t=1314794791, M3_Ab1PrR_z=0x7ed538, M3_D5xROs__result=0x934c08) at DateBsd.m3:31 #8 0x004387d7 in RCSDate__FromTime (M3_CtKayy_t=1314794791) at RCSDate.m3:54 #9 0x004467ba in RCSFile__Import (M3_Bd56fi_p=0x9d9008, M3_Bd56fi_revNum=0x9d87c8, M3_Bd56fi_author=0x763020, M3_Bd56fi_state=0x763040, M3_AcxOUs_logLines=12) at RCSFile.m3:413 #10 0x004077de in CheckoutUpdater__Update (M3_CTVCUv_self=0x9d8980, M3_CzVV2w_sfr=0x7ff2e0, M3_Bd56fi_name=0x9d8788, M3_AicXUJ_toAttic=0 '\0', M3_DsoVVS_proto=0x7f74a8, M3_AeHwgK_trace=0x7f8710, M3_EkTcCb_protoRd=0x9d05b8, M3_BxxOH1_wr=0x9d8e98, M3_AQMw24_status=0x935f48) at CheckoutUpdater.m3:111 #11 0x00416ab4 in Updater__UpdateFile (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_Bd56fi_name=0x9d8788, M3_AicXUJ_toAttic=0 '\0', M3_DMoNGc_fup=0x9d8980, M3_AicXUJ_isFixup=0 '\0') at Updater.m3:641 #12 0x004155ce in Updater__UpdateCollection (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:458 #13 0x00412baf in Updater__UpdateBatch (M3_DBUV6k_self=0x7fee38, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:151 #14 0x0041268a in Updater__Apply (M3_DBUV6k_self=0x7fee38) at Updater.m3:90 #15 0x0049d290 in ThreadPosix__DetermineContext (M3_AJWxb1_oldSP=0x7edfd0) at ThreadPosix.m3:1127 #16 0x0048d34d in RTCollector__LongAlloc (M3_Cwb5VA_dataSize=4337239, M3_Cwb5VA_dataAlignment=8577024, M3_AOtCKl_currentPtr=0x7f8, M3_AOtCKl_currentBoundary=0x76c8f8, M3_CCsHD8_currentPage=0x0, M3_CCsHD8_stack=0x0, M3_D8qd0n_allocMode=144 '\220', M3_AicXUJ_pure=120 'x') at RTCollector.m3:1530 #17 0x7fffc428 in ?? () #18 0x7fffd990 in ?? () #19 0x7fffda78 in ?? () #20 0x7fffda58 in ?? () #21 0x in ?? () #22 0x in ?? () #23 0x1fa0037f in ?? () #24 0x in ?? () #25 0x007f76c0 in ?? () #26 0x007f76c0 in ?? () #27 0x00492699 in RTMisc__Copy (M3_AJWxb1_src=Cannot access memory at address 0xfffb ) at RTMisc.m3:19 Previous frame inner to this frame (corrupt stack?) (gdb) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Fri, Sep 09, 2011 at 04:19:42PM +0200, Oliver Lehmann wrote: Kostik Belousov kostik...@gmail.com wrote: I do not know, I was curious about 'illegal instruction' signal, which would indicate a problem in the compilation environment. Now you get segmentation violation, that is usually caused by a bug in the program itself. running it outside gdb still results in an 'illegal instruction' error. Why it gets to segmentation violation inside gdb I just don't know. nudel# ./client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Illegal instruction (core dumped) nudel# gdb ./client/FBSD_AMD64/cvsup cvsup.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Core was generated by `cvsup'. Program terminated with signal 4, Illegal instruction. #0 0x004d24c6 in tzload () (gdb) bt #0 0x004d24c6 in tzload () Try to do disas 0x4d24c6 0x4d24c6+30 from gdb prompt with the loaded core. pgpz3aHMHVkEn.pgp Description: PGP signature
Re: cvsup broken on amd64?
Kostik Belousov kostik...@gmail.com wrote: On Fri, Sep 09, 2011 at 04:19:42PM +0200, Oliver Lehmann wrote: (gdb) bt #0 0x004d24c6 in tzload () Try to do disas 0x4d24c6 0x4d24c6+30 from gdb prompt with the loaded core. (gdb) disas 0x4d24c6 0x4d24c6+30 Dump of assembler code from 0x4d24c6 to 0x4d24e4: 0x004d24c6 tzload+86: callq 0x4db370 issetugid 0x004d24cb tzload+91: test %eax,%eax 0x004d24cd tzload+93: jne0x4d25e0 tzload+368 0x004d24d3 tzload+99: movzbl (%rbx),%ebp 0x004d24d6 tzload+102:cmp$0x3a,%bpl 0x004d24da tzload+106:jne0x4d24e3 tzload+115 0x004d24dc tzload+108:add$0x1,%rbx 0x004d24e0 tzload+112:movzbl (%rbx),%ebp 0x004d24e3 tzload+115:cmp$0x2f,%bpl End of assembler dump. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Fri, Sep 09, 2011 at 04:34:54PM +0200, Oliver Lehmann wrote: Kostik Belousov kostik...@gmail.com wrote: On Fri, Sep 09, 2011 at 04:19:42PM +0200, Oliver Lehmann wrote: (gdb) bt #0 0x004d24c6 in tzload () Try to do disas 0x4d24c6 0x4d24c6+30 from gdb prompt with the loaded core. (gdb) disas 0x4d24c6 0x4d24c6+30 Dump of assembler code from 0x4d24c6 to 0x4d24e4: 0x004d24c6 tzload+86: callq 0x4db370 issetugid 0x004d24cb tzload+91: test %eax,%eax 0x004d24cd tzload+93: jne0x4d25e0 tzload+368 0x004d24d3 tzload+99: movzbl (%rbx),%ebp 0x004d24d6 tzload+102:cmp$0x3a,%bpl 0x004d24da tzload+106:jne0x4d24e3 tzload+115 0x004d24dc tzload+108:add$0x1,%rbx 0x004d24e0 tzload+112:movzbl (%rbx),%ebp 0x004d24e3 tzload+115:cmp$0x2f,%bpl End of assembler dump. Ok, please do the following: run cvsup under the gdb. When SIGSEGV is raised, from the gdb prompt, do: 1. info registers $rsp 2. info program This should print you the pid of the process, then do 3. shell procstat -v pid I suspect that modula 3 system uses the kind of green threads, and the default thread stack size is simply too small for amd64. This is consistent with SIGILL when running standalone, but SIGSEGV under debugger. pgpNkNsofaEKD.pgp Description: PGP signature
Re: cvsup broken on amd64?
On Fri, Sep 09, 2011 at 05:55:13PM +0300, Kostik Belousov wrote:
On Fri, Sep 09, 2011 at 04:34:54PM +0200, Oliver Lehmann wrote:
Kostik Belousov kostik...@gmail.com wrote:
On Fri, Sep 09, 2011 at 04:19:42PM +0200, Oliver Lehmann wrote:
(gdb) bt
#0 0x004d24c6 in tzload ()
Try to do disas 0x4d24c6 0x4d24c6+30 from gdb prompt with the loaded
core.
(gdb) disas 0x4d24c6 0x4d24c6+30
Dump of assembler code from 0x4d24c6 to 0x4d24e4:
0x004d24c6 tzload+86: callq 0x4db370 issetugid
0x004d24cb tzload+91: test %eax,%eax
0x004d24cd tzload+93: jne0x4d25e0 tzload+368
0x004d24d3 tzload+99: movzbl (%rbx),%ebp
0x004d24d6 tzload+102:cmp$0x3a,%bpl
0x004d24da tzload+106:jne0x4d24e3 tzload+115
0x004d24dc tzload+108:add$0x1,%rbx
0x004d24e0 tzload+112:movzbl (%rbx),%ebp
0x004d24e3 tzload+115:cmp$0x2f,%bpl
End of assembler dump.
Ok, please do the following:
run cvsup under the gdb. When SIGSEGV is raised, from the gdb prompt, do:
1. info registers $rsp
2. info program
This should print you the pid of the process, then do
3. shell procstat -v pid
I suspect that modula 3 system uses the kind of green threads, and
the default thread stack size is simply too small for amd64. This is
consistent with SIGILL when running standalone, but SIGSEGV under
debugger.
Also, you might try to test my guesswork, by adding the following
patch to lang/ezm3 and rebuilding it, then rebuilding cvsup port:
--- libs/m3core/src/thread/POSIX/ThreadPosix.m3.orig2011-09-09
17:58:12.867431639 +0300
+++ libs/m3core/src/thread/POSIX/ThreadPosix.m3 2011-09-09 17:58:30.380428486
+0300
@@ -180,7 +180,7 @@
pausedThreads : T;
selected_interval:= UTime{0, 100 * 1000};
- defaultStackSize := 3000;
+ defaultStackSize := 1;
stack_grows_down: BOOLEAN;
pgpf3Qfd6XtRX.pgp
Description: PGP signature
Re: cvsup broken on amd64?
Kostik Belousov kostik...@gmail.com wrote: On Fri, Sep 09, 2011 at 05:55:13PM +0300, Kostik Belousov wrote: Ok, please do the following: run cvsup under the gdb. When SIGSEGV is raised, from the gdb prompt, do: 1. info registers $rsp 2. info program This should print you the pid of the process, then do 3. shell procstat -v pid (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () (gdb) info registers $rsp rsp0x916c98 0x916c98 (gdb) info program Using the running image of child process 14704. Program stopped at 0x4d24c6. It stopped with signal SIGSEGV, Segmentation fault. (gdb) nudel# procstat -v 14704 PID STARTEND PRT RES PRES REF SHD FL TP PATH 14704 0x40 0x53f000 r-x 2190 1 0 C- vn /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup 14704 0x73f000 0x7bf000 rw- 1280 1 0 C- vn /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup 14704 0x7bf000 0x844000 rw- 1190 15 0 -- df 14704 0x844000 0x845000 r--10 15 0 -- df 14704 0x845000 0x867000 rw- 340 15 0 -- df 14704 0x867000 0x868000 r--10 15 0 -- df 14704 0x868000 0x88a000 rw- 340 15 0 -- df 14704 0x88a000 0x88b000 r--10 15 0 -- df 14704 0x88b000 0x8ad000 rw- 340 15 0 -- df 14704 0x8ad000 0x8ae000 r--10 15 0 -- df 14704 0x8ae000 0x8d rw- 340 15 0 -- df 14704 0x8d 0x8d1000 r--10 15 0 -- df 14704 0x8d1000 0x8f3000 rw- 340 15 0 -- df 14704 0x8f3000 0x8f4000 r--10 15 0 -- df 14704 0x8f4000 0x916000 rw- 340 15 0 -- df 14704 0x916000 0x917000 r--10 15 0 -- df 14704 0x917000 0xa87000 rw- 3440 15 0 -- df 147040x800740x800743000 rw-20 1 0 -- df 147040x8007430000x800751000 r-- 120 1 0 -- vn /mnt/files/FreeBSD/9.0/src/crypto/openssl/ssl/s3_lib.c 14704 0x7ffbf000 0x7ffdf000 rwx10 1 0 -- df 14704 0x7ffdf000 0x7000 rwx 110 1 0 -- df 14704 0x7000 0x8000 r-x10 47 0 CN ph nudel# Also, you might try to test my guesswork, by adding the following patch to lang/ezm3 and rebuilding it, then rebuilding cvsup port: [made a file below ezm3/files, cleaned the workdir, reinstalled it cleaned cvsup, rebuilt it] no change so far (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () (gdb) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Fri, Sep 09, 2011 at 06:20:57PM +0200, Oliver Lehmann wrote: Kostik Belousov kostik...@gmail.com wrote: On Fri, Sep 09, 2011 at 05:55:13PM +0300, Kostik Belousov wrote: Ok, please do the following: run cvsup under the gdb. When SIGSEGV is raised, from the gdb prompt, do: 1. info registers $rsp 2. info program This should print you the pid of the process, then do 3. shell procstat -v pid (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () (gdb) info registers $rsp rsp0x916c98 0x916c98 (gdb) info program Using the running image of child process 14704. Program stopped at 0x4d24c6. It stopped with signal SIGSEGV, Segmentation fault. (gdb) nudel# procstat -v 14704 PID STARTEND PRT RES PRES REF SHD FL TP PATH 14704 0x40 0x53f000 r-x 2190 1 0 C- vn /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup 14704 0x73f000 0x7bf000 rw- 1280 1 0 C- vn /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup 14704 0x7bf000 0x844000 rw- 1190 15 0 -- df 14704 0x844000 0x845000 r--10 15 0 -- df 14704 0x845000 0x867000 rw- 340 15 0 -- df 14704 0x867000 0x868000 r--10 15 0 -- df 14704 0x868000 0x88a000 rw- 340 15 0 -- df 14704 0x88a000 0x88b000 r--10 15 0 -- df 14704 0x88b000 0x8ad000 rw- 340 15 0 -- df 14704 0x8ad000 0x8ae000 r--10 15 0 -- df 14704 0x8ae000 0x8d rw- 340 15 0 -- df 14704 0x8d 0x8d1000 r--10 15 0 -- df 14704 0x8d1000 0x8f3000 rw- 340 15 0 -- df 14704 0x8f3000 0x8f4000 r--10 15 0 -- df 14704 0x8f4000 0x916000 rw- 340 15 0 -- df 14704 0x916000 0x917000 r--10 15 0 -- df 14704 0x917000 0xa87000 rw- 3440 15 0 -- df %rsp value is 0x917000, so this is definitely stack overflow. 147040x800740x800743000 rw-20 1 0 -- df 147040x8007430000x800751000 r-- 120 1 0 -- vn /mnt/files/FreeBSD/9.0/src/crypto/openssl/ssl/s3_lib.c 14704 0x7ffbf000 0x7ffdf000 rwx10 1 0 -- df 14704 0x7ffdf000 0x7000 rwx 110 1 0 -- df 14704 0x7000 0x8000 r-x10 47 0 CN ph nudel# Also, you might try to test my guesswork, by adding the following patch to lang/ezm3 and rebuilding it, then rebuilding cvsup port: [made a file below ezm3/files, cleaned the workdir, reinstalled it cleaned cvsup, rebuilt it] no change so far (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () (gdb) I need the same information from the gdb for this crash too, with cvsup rebuilt using the patched ezm3. pgpjB33Vzig07.pgp Description: PGP signature
Re: cvsup broken on amd64?
Kostik Belousov kostik...@gmail.com wrote: On Fri, Sep 09, 2011 at 06:20:57PM +0200, Oliver Lehmann wrote: (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () (gdb) I need the same information from the gdb for this crash too, with cvsup rebuilt using the patched ezm3. Mh... looks like the same output to me (gdb) info registers $rsp rsp0x916c98 0x916c98 (gdb) info program Using the running image of child process 62191. Program stopped at 0x4d24c6. It stopped with signal SIGSEGV, Segmentation fault. (gdb) nudel# procstat -v 62191 PID STARTEND PRT RES PRES REF SHD FL TP PATH 62191 0x40 0x53f000 r-x 2180 1 0 C- vn /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup 62191 0x73f000 0x7bf000 rw- 930 1 0 C- vn /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup 62191 0x7bf000 0x844000 rw- 1190 15 0 -- df 62191 0x844000 0x845000 r--10 15 0 -- df 62191 0x845000 0x867000 rw- 340 15 0 -- df 62191 0x867000 0x868000 r--10 15 0 -- df 62191 0x868000 0x88a000 rw- 340 15 0 -- df 62191 0x88a000 0x88b000 r--10 15 0 -- df 62191 0x88b000 0x8ad000 rw- 340 15 0 -- df 62191 0x8ad000 0x8ae000 r--10 15 0 -- df 62191 0x8ae000 0x8d rw- 340 15 0 -- df 62191 0x8d 0x8d1000 r--10 15 0 -- df 62191 0x8d1000 0x8f3000 rw- 340 15 0 -- df 62191 0x8f3000 0x8f4000 r--10 15 0 -- df 62191 0x8f4000 0x916000 rw- 340 15 0 -- df 62191 0x916000 0x917000 r--10 15 0 -- df 62191 0x917000 0xa87000 rw- 3440 15 0 -- df 621910x800740x800743000 rw-20 1 0 -- df 621910x8007430000x800751000 r-- 120 1 0 -- vn /mnt/files/FreeBSD/9.0/src/crypto/openssl/ssl/s3_lib.c 62191 0x7ffbf000 0x7ffdf000 rwx10 1 0 -- df 62191 0x7ffdf000 0x7000 rwx 110 1 0 -- df 62191 0x7000 0x8000 r-x10 50 0 CN ph nudel# ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On 09/08/11 14:52, b. f. wrote: I have an Atom 330 with 9.0-BETA2/amd64 installed. I did a pkg_add -r cvsup-without-gui at first after installation. Using cvsup, resulted in a core dump (illegal instruction). I then removed all ports, and installed cvsup-without-gui from source. Started cvsup... core dump again. I then got the cvsup binary from a FreeBSD 8 i386 system, installed compat8x and also copied the missing libutil.so.8 from FreeBSD/i386 and cvsuped the source (8.2-STABLE i386 cvsup worked). Then I rebuilt world, kernel (removed all debugging options from GENERIC). Then I removed all ports once more and reinstalled cvsup-without-gui from ports once more. And now again... It may be broken -- I seem to recall some earlier complaints about problems on one of the list. But is there a reason why you are attempting to use it, when /usr/bin/csup is available, and is generally thought to be superior? b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Does cvsup work for anyone? At what point should cvsup just be a symlink to csup? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
I have an Atom 330 with 9.0-BETA2/amd64 installed. I did a pkg_add -r cvsup-without-gui at first after installation. Using cvsup, resulted in a core dump (illegal instruction). I then removed all ports, and installed cvsup-without-gui from source. Started cvsup... core dump again. I then got the cvsup binary from a FreeBSD 8 i386 system, installed compat8x and also copied the missing libutil.so.8 from FreeBSD/i386 and cvsuped the source (8.2-STABLE i386 cvsup worked). Then I rebuilt world, kernel (removed all debugging options from GENERIC). Then I removed all ports once more and reinstalled cvsup-without-gui from ports once more. And now again... It may be broken -- I seem to recall some earlier complaints about problems on one of the list. But is there a reason why you are attempting to use it, when /usr/bin/csup is available, and is generally thought to be superior? b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
