le!
>
> http://www.silby.com/valgrind_freebsd_3.tar.gz
>
> But don't send me questions about it - I'm not an expert on it, I'm just
> the guy who grabbed it from perforce and found that it seems to work. :)
Could you please prov
Here is the patch.
--- coregrind/vg_syscalls.c.origFri Jul 16 19:21:08 2004
+++ coregrind/vg_syscalls.c Wed Sep 14 22:13:44 2005
@@ -1369,6 +1369,38 @@
&tst->m_eflags,
arg1, arg2);
break;
+case
Doug,
hackers,
a user of the valgrind port reported that it crashed due to an unhandled
sysarch call (ports/86007).
I found out, that this was because of the get_fsbase, set_fsbase,
get_gsbase and set_gsbase calls, which were introduced in FreeBSD 6.
I'd be happy if somebody could review my atta
[EMAIL PROTECTED] wrote:
> On all installations of FreeBSD I?ve ever done in the past,
>
> netstat -an
>
> displays LISTENing servers and any tcp connection in any state.
>
> On the 5.3 I have installed here ( updated to RELENG_5_3 + build/installworld
> ), this command only
> shows only this;
> --- coregrind/vg_proxylwp.c~ Mon Aug 23 15:47:33 2004
> +++ coregrind/vg_proxylwp.c Mon Aug 23 15:48:42 2004
> @@ -596,6 +596,8 @@
> static const vki_kstack_t ss = { .ss_flags = VKI_SS_DISABLE };
>
> #if __FreeBSD__ == 5
> + VG_(message)(Vg_UserMsg, "Locking#1 mutex %p/%p", &px->mutex
Miguel Mendez wrote:
> Hi all,
>
> Is anybody using valgrind on 5.3BETA1 or newer? I've been using it for a
> while on 5.2.1 without any problems, until I upgraded my system to
> RELENG_5. The program works but it never exits after running your
> program, it gets stuck into `umtx' state indefinite
Daniel O'Connor wrote:
> There is valgrind..
> http://www.rabson.org/#valgrind
>
> I thought it was in ports but I can't see it.
Hi,
as I pointed out in another message of this thread, the port is ready
and waiting for a committer.
Simon
signature.asc
Description: Digital signature
> I just wanted to know what programs any of you have used to track down a
> memory leak in your programs?
this reminds me of something... :-/
I created a port for Doug Rabson's FreeBSD port[1] of valgrind [2]. He
considered my work ready for the ports tree, but he also said that that
he doesn't
Danny Braniss wrote:
> Looking at the driver, i see that somethings changed :-) but
> can't find much documentation, (yes i know the source is the force)
>
> While im studying the driver, some program/documentation would speed up
> things.
Hi,
did you already have a look at the following t
Hi,
I tested your patch, and it worked, but I had to modify the following
things:
Fetch libmapc. and libmap.h from the CVS repository (latest revisions).
Add libmap.c to SRC section in Makefile.
After these changes, I was able to compile a ld-elf.so with libmap
support.
> libstdc++-libc6.2-2.so
> Could somebody please review my patch - if there are no objections (but
> I am sure there are some more details that can be improved), I will
> write a PR.
I have filed a PR in order to preserve this patch. It can be found here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=55539
Regards,
Simon
> imho - expensive algorithm... i want to see anything more simple...
> like "gtok()" instead "es_strsep() + remove_escapes()"?
I have adopted my patch to use your neat gtok() function, but I came to
the conclusion that a two-pass algorithm is necessary:
The first pass detects whether a line fro
Hi,
> Check PR 37569: This bugged the hell out of me also, so I created a
> patch to allow enclosing the device name in quotes. The PR was logged
> over a year ago: I can't remember the details, but the source has been
> sitting silently in my tree and working since then. Whatever way the
> proble
Hi Terry,
> You need to add '\\' to the list of characters that can be escaped,
> or you've just traded the inability to specify '\t' or ' ' for an
> inability to speciy '\\'.
Oh yes, I have overlook this special case. I revised my patch in order
to get this right.
Simon
--- fstab.c.orig
Hi,
> For all the 'good rules' of orthonogolity and consistency etc
> it is a good thing, however I still feel that at the level of
> the fstab where you are mounting entire file system trees,
> the simplest naming formats are probably the best.
> A philosophical point only, but it would keep t
Hi,
> This very discussion came up in -questions a few months ago (or maybe it was
> late last year). The conclusion was that unless someone rewrites the
> /etc/fstab parsing routines in libc to support quoted and/or escaped spaces,
> we'll never be able to mount filesystems that have spaces in t
> Just a thort, not having tried it ..
>
> does either of the 'standard' methods of including spaces actually work
> in fstab ??
>
> I speak of quoting (either single or double) and backslashing the space
>
> "/mnt/space/silly long dirname/filename also with spaces"
>
> or
>
> /mnt/space/silly
Hi -hackers,
discussing some modifications for the sysutils/linneighborhood port,
Heiner Eichmann and me came across the following problem:
getfsent(3) will fail, if the name of the file system or the mount point
contains whitespaces, be them escaped or not (file system names with
spaces occur qu
Hi,
> > cat test.c
> #include
> #include
>
It will link, when you wrap the include with an extern "C" statement:
extern "C" {
#include
}
This should probably by handled by the library header itself, here is a
patch:
--- histedit.h.orig Mon Jul 14 01:37:43 2003
+++ histedit.h
Hi,
> :U Actually, Matt, the property you've stated is much more
> :common than you seem to believe. If you generate a sequence
> :N = ( N + Stride ) % ArraySize
> :then you will visit every element of (0 ... ArraySize-1) as long as
>
> I was just answering a question. Most peo
20 matches
Mail list logo
