Menu
▾
▴
felix-impl
|
From: Rhythmic F. <rfi...@gm...> - 2011-09-28 10:29:02
|
I just tracked down a CPU burning bug to felix's waitable_bool class:
// a waitable boolean.
class PTHREAD_EXTERN waitable_bool {
flx::pthread::flx_mutex_t cv_lock; // to work with the condition var
flx::pthread::flx_condv_t finished_cond;
bool finished; // might seem redundant, but that's how CVs work.
public:
waitable_bool();
void wait_until_true();
void signal_true();
};
Felix uses it to politely ask threads to quit, which works fine.
What I'd forgotten (or never knew) is that this is a one shot object -
once set to true, it's always true and all further calls to
wait_until_true correctly return immediately, hence my CPU burn.
I'd like to modify it by adding a set_to_false method (not signal,
because there's no wait_until_false!).
I'm writing to this list to see if that raises any alarm bells (what
if there are multiple waiters? in felix there aren't, nor are there in
my use) and it would be nice to check such a change in, even though my
branch of the demux/pthread stuff is fossilised at svn commit #1695
because after that the lightweight pthread wrapper pulled in a bunch
of garbage collection stuff.
RF
|
|
From: Rhythmic F. <rfi...@gm...> - 2011-09-28 10:45:38
|
I added a reset_and_wait_until_true method.
Any dire predictions?
RF
On 28 September 2011 12:28, Rhythmic Fistman <rfi...@gm...> wrote:
> I just tracked down a CPU burning bug to felix's waitable_bool class:
>
> // a waitable boolean.
> class PTHREAD_EXTERN waitable_bool {
> flx::pthread::flx_mutex_t cv_lock; // to work with the condition var
> flx::pthread::flx_condv_t finished_cond;
> bool finished; // might seem redundant, but that's how CVs work.
> public:
> waitable_bool();
>
> void wait_until_true();
> void signal_true();
> };
>
> Felix uses it to politely ask threads to quit, which works fine.
>
> What I'd forgotten (or never knew) is that this is a one shot object -
> once set to true, it's always true and all further calls to
> wait_until_true correctly return immediately, hence my CPU burn.
>
> I'd like to modify it by adding a set_to_false method (not signal,
> because there's no wait_until_false!).
> I'm writing to this list to see if that raises any alarm bells (what
> if there are multiple waiters? in felix there aren't, nor are there in
> my use) and it would be nice to check such a change in, even though my
> branch of the demux/pthread stuff is fossilised at svn commit #1695
> because after that the lightweight pthread wrapper pulled in a bunch
> of garbage collection stuff.
>
> RF
>
|
|
From: john s. <sk...@us...> - 2011-10-27 08:49:12
|
On 28/09/2011, at 8:28 PM, Rhythmic Fistman wrote: FYI: I've just returned to Cairns from Papua New Guinea! I may start some Felix work again soon. -- john skaller sk...@us... |
|
From: Rhythmic F. <rfi...@gm...> - 2011-10-27 08:10:24
|
On 27 October 2011 08:41, john skaller <sk...@us...> wrote: > > On 28/09/2011, at 8:28 PM, Rhythmic Fistman wrote: > > FYI: I've just returned to Cairns from Papua New Guinea! > I may start some Felix work again soon. cool! I was starting to get worried |
|
From: john s. <sk...@us...> - 2011-10-27 16:13:02
|
On 27/10/2011, at 11:51 PM, Jeff Schultz wrote: > On Thu, Oct 27, 2011 at 10:10:17AM +0200, Rhythmic Fistman wrote: >>> FYI: I've just returned to Cairns from Papua New Guinea! >>> I may start some Felix work again soon. >> >> cool! I was starting to get worried > > Warm! Cairns: Fine. Min 21 Max 30 UV 13 > > Humidity 90% at 0500. Stinky .. PNG was hotter but one could jump in the sea and go snorkelling anytime. Best snorkelling (and diving) in the world. -- john skaller sk...@us... |
|
From: john s. <sk...@us...> - 2011-10-27 22:26:13
|
On 28/10/2011, at 3:42 AM, Erick Tryzelaar wrote: > That's great. That sounds like an awesome trip. How long was the sail? Six weeks all up. Well, doing resume now. Hey, Felix-lang.org is still running! Well .. now I need to sort out repository and build system ;( And fix the {bug} that {word} are still not formatted correctly in .fdoc files online even though the current software on my box does it. -- john skaller sk...@us... |
|
From: john s. <sk...@us...> - 2011-10-28 12:44:51
|
Erick .. why is the web server still running?
What I mean is: there is STILL the bug that {xxx} is not correctly typeset online.
Compare:
http://localhost:1234/web/Easy_to_Read_and_Write.fdoc
where it says " "variable length array y" (y in typewritter font) with
http://felix-lang.org/Easy_to_Read_and_Write.fdoc
where it says "variable length array {y}"
The latter simply can't be the most recent version of Felix webserver.
Ps shows:
11908 ? Ss 0:00 /bin/sh -e -c privbind -u felixweb /usr/local/bin/webserver --port=80 --root=/usr/local/lib/felix/felix-latest/w
11910 ? Sl 3:02 /usr/local/bin/webserver --port=80 --root=/usr/local/lib/felix/felix-latest/web/
11912 ? S 0:00 privbind -u felixweb /usr/local/bin/webserver --port=80 --root=/usr/local/lib/felix/felix-latest/web/
17686 ? Ss 0:00 /bin/sh -e -c privbind -u felixweb /usr/local/bin/webserver --port=1116 /bin/sh
17688 ? Sl 1:05 /usr/local/bin/webserver --port=1116
17690 ? S 0:00 privbind -u felixweb /usr/local/bin/webserver --port=1116
huh?
Well, all those commands are running /usr/local/bin/webserver ...
Now, if I do this:
skaller@felix:~$ webserver --root=/usr/local/lib/felix/felix-latest/web/
and look at
http://felix-lang.org:1234/Easy_to_Read_and_Write.fdoc
It all works right (with the "y" in typewritter font). I am baffled!
OOoo .. and now the webserver on port 1116 has crashed :)
Grrr :)
--
john skaller
sk...@us...
|
|
From: john s. <sk...@us...> - 2011-10-28 13:47:06
|
On 28/10/2011, at 11:43 PM, john skaller wrote: > > Compare: > > http://localhost:1234/web/Easy_to_Read_and_Write.fdoc > > where it says " "variable length array y" (y in typewritter font) with > > http://felix-lang.org/Easy_to_Read_and_Write.fdoc > > where it says "variable length array {y}" > > The latter simply can't be the most recent version of Felix webserver. Ah .. I think I fixed it! The command to start the port 1116 server failed to specify a root. Since user felixweb is actually using MY home directory some stuff must have come from the wrong place. Upstart .. seems quite nice now I bothered to actually read the docs :) -- john skaller sk...@us... |
|
From: john s. <sk...@us...> - 2011-10-29 00:50:28
|
On 28/09/2011, at 8:28 PM, Rhythmic Fistman wrote:
> I just tracked down a CPU burning bug to felix's waitable_bool class:
>
> // a waitable boolean.
> class PTHREAD_EXTERN waitable_bool {
> flx::pthread::flx_mutex_t cv_lock; // to work with the condition var
> flx::pthread::flx_condv_t finished_cond;
> bool finished; // might seem redundant, but that's how CVs work.
> public:
> waitable_bool();
>
> void wait_until_true();
> void signal_true();
> };
>
> Felix uses it to politely ask threads to quit, which works fine.
>
> What I'd forgotten (or never knew) is that this is a one shot object -
> once set to true, it's always true and all further calls to
> wait_until_true correctly return immediately, hence my CPU burn.
>
> I'd like to modify it by adding a set_to_false method (not signal,
> because there's no wait_until_false!).
> I'm writing to this list to see if that raises any alarm bells (what
> if there are multiple waiters? in felix there aren't, nor are there in
> my use) and it would be nice to check such a change in, even though my
> branch of the demux/pthread stuff is fossilised at svn commit #1695
> because after that the lightweight pthread wrapper pulled in a bunch
> of garbage collection stuff.
Well feel free to check any change in.
But more importantly I think: we need to reorganise Felix so you can use
the most recent version.
What's the problem with the GC code being pulled in?
A stub GC could be made (that throws an exception if any serious attempt
is made to use the gc). More "seriously" we could look at making the GC optional.
More "seriously" than that, we could look at a long term goal: to generate pure
C/C++ code (requiring no flx_run). Many Felix programs don't actually use
any p or f threading and so don't actually need flx_run.
Decoupling stuff isn't easy. Code in flx_run will call the collector entry points
in various places because if the collector IS being used it's necessary.
WRT my other mail on work schedule: I have big plans for making Felix more
dynamic (this was always intended!). Recently a way to incorporate custom
data structures into the gc was added, primarily this was to support Judy arrays.
However it could also be used to support C++ Vectors containing Felix pointers.
In fact the hard bit is distinguising between such vectors requiring scanning by
the gc and those that don't (eg vectors of ints).
I mention this because this is the first step towards a more dynamic type system.
The gc previously used an array of offsets to find pointers in an object, now
it will take an arbitrary scanning function. The ability to create, copy, move, and delete
dynamically defined types can also be added eventually.
Oh, and backstepping a bit: custom event loops such as the kind RF is using
need to be supported too. In fact it would be nice to be able to embed the whole
Felix system as callback of a third party event loops (of course that makes
using threads for async I/O a little tricky .. :)
--
john skaller
sk...@us...
|
|
From: john s. <sk...@us...> - 2011-10-29 14:22:16
|
flx_cp isn't working .. it seems I;m not using JudySLIns correctly: tools/flx_cp web "(.*)" 'xxx\1' --test //////// Consider file download.html Listing ds=d->s Listing sd=s->d subs 1 -> download.html [pre-Ins] Src = web/download.html Dst= xxxdownload.html [post-Ins sd] Src = web/download.html Dst= xxxdownload.html [post-Ins ds] Src = web/download.html Dst= xxxdownload.html Copy web/download.html -> xxxdownload.html Consider file Easy_to_Deploy.fdoc Listing ds=d->s Recorded copy xxxdownload.html <- web/download.html Listing sd=s->d Recorded copy web/download.html -> xxxdownload.html subs 1 -> Easy_to_Deploy.fdoc [pre-Ins] Src = web/Easy_to_Deploy.fdoc Dst= xxxEasy_to_Deploy.fdoc [post-Ins sd] Src = web/Easy_to_Deploy.fdoc Dst= xxxEasy_to_Deploy.fdoc [post-Ins ds] Src = web/Easy_to_Deploy.fdoc Dst= xxxEasy_to_Deploy.fdoc Copy web/Easy_to_Deploy.fdoc -> xxxEasy_to_Deploy.fdoc Consider file Easy_to_Read_and_Write.fdoc Listing ds=d->s Recorded copy xxxEasy_to_Deploy.fdoc <- web/Easy_to_Deploy.fdoc Recorded copy xxxdasy_oad.html <- web/download.html Listing sd=s->d Recorded copy web/asy__to_htmloy.fdoc -> xxxEasy_to_Deploy.fdoc Recorded copy web/asy_loadhtmll -> xxxdownload.html subs 1 -> Easy_to_Read_and_Write.fdoc [pre-Ins] Src = web/Easy_to_Read_and_Write.fdoc Dst= xxxEasy_to_Read_and_Write.fdoc [post-Ins sd] Src = web/Easy_to_Read_and_Write.fdoc Dst= xxxEasy_to_Read_and_Write.fdoc [post-Ins ds] Src = web/Easy_to_Read_and_Write.fdoc Dst= xxxEasy_to_Read_and_Write.fdoc Copy web/Easy_to_Read_and_Write.fdoc -> xxxEasy_to_Read_and_Write.fdoc Consider file Easy_to_Read_and_Write_01.cpp Listing ds=d->s Recorded copy xxxEasy_to_Dead_y.fdoc <- web/Easy_to_Deploy.fdoc Recorded copy xxxEasy_to_Read_and_Write.fdoc <- web/Easy_to_Read_and_Write.fdoc Recorded copy xxxdasy_oad.html <- web/download.html Listing sd=s->d Recorded copy web/asy__to_html_andWritte.fdoc -> xxxEasy_to_Read_and_Write.fdoc Segmentation fault /////////// clearly some overwiting happening .... -- john skaller sk...@us... |
|
From: john s. <sk...@us...> - 2011-10-29 14:22:16
|
flx_cp isn't working .. it seems I;m not using JudySLIns correctly: tools/flx_cp web "(.*)" 'xxx\1' --test //////// Consider file download.html Listing ds=d->s Listing sd=s->d subs 1 -> download.html [pre-Ins] Src = web/download.html Dst= xxxdownload.html [post-Ins sd] Src = web/download.html Dst= xxxdownload.html [post-Ins ds] Src = web/download.html Dst= xxxdownload.html Copy web/download.html -> xxxdownload.html Consider file Easy_to_Deploy.fdoc Listing ds=d->s Recorded copy xxxdownload.html <- web/download.html Listing sd=s->d Recorded copy web/download.html -> xxxdownload.html subs 1 -> Easy_to_Deploy.fdoc [pre-Ins] Src = web/Easy_to_Deploy.fdoc Dst= xxxEasy_to_Deploy.fdoc [post-Ins sd] Src = web/Easy_to_Deploy.fdoc Dst= xxxEasy_to_Deploy.fdoc [post-Ins ds] Src = web/Easy_to_Deploy.fdoc Dst= xxxEasy_to_Deploy.fdoc Copy web/Easy_to_Deploy.fdoc -> xxxEasy_to_Deploy.fdoc Consider file Easy_to_Read_and_Write.fdoc Listing ds=d->s Recorded copy xxxEasy_to_Deploy.fdoc <- web/Easy_to_Deploy.fdoc Recorded copy xxxdasy_oad.html <- web/download.html Listing sd=s->d Recorded copy web/asy__to_htmloy.fdoc -> xxxEasy_to_Deploy.fdoc Recorded copy web/asy_loadhtmll -> xxxdownload.html subs 1 -> Easy_to_Read_and_Write.fdoc [pre-Ins] Src = web/Easy_to_Read_and_Write.fdoc Dst= xxxEasy_to_Read_and_Write.fdoc [post-Ins sd] Src = web/Easy_to_Read_and_Write.fdoc Dst= xxxEasy_to_Read_and_Write.fdoc [post-Ins ds] Src = web/Easy_to_Read_and_Write.fdoc Dst= xxxEasy_to_Read_and_Write.fdoc Copy web/Easy_to_Read_and_Write.fdoc -> xxxEasy_to_Read_and_Write.fdoc Consider file Easy_to_Read_and_Write_01.cpp Listing ds=d->s Recorded copy xxxEasy_to_Dead_y.fdoc <- web/Easy_to_Deploy.fdoc Recorded copy xxxEasy_to_Read_and_Write.fdoc <- web/Easy_to_Read_and_Write.fdoc Recorded copy xxxdasy_oad.html <- web/download.html Listing sd=s->d Recorded copy web/asy__to_html_andWritte.fdoc -> xxxEasy_to_Read_and_Write.fdoc Segmentation fault /////////// clearly some overwiting happening .... -- john skaller sk...@us... |
|
From: john s. <sk...@us...> - 2011-10-29 22:40:57
|
Hi, I'm having some problems with JudySL .. not sure what's going on.
First a test program written in Felix:
/////
open Judy;
x := JSLArray();
var je: JError_t;
var pv : &word;
var buffer: &char = C_hack::cast[&char] (C_hack::malloc(1000));
for var i in 0 upto 100 do
var j = Cstdlib::rand();
strcpy(buffer, j.str.cstr);
println$ str i + " --> " + str j + " = " + buffer;
JudySLIns(x,buffer,&je,&pv);
if C_hack::cast[long] (*pv) != 0l do println "DUPLICATE"; done
*pv = C_hack::cast[word] i;
done
println "Listing ds=d->s";
*buffer=char 0;
JudySLFirst(x,buffer,&je,&pv);
var k= 0;
whilst not isNULL pv do
j := C_hack::cast[int] (*pv);
println$ "Recorded copy " + k.str + ": " + string buffer + " => " + str j;
++k;
JudySLNext(x,buffer,&je,&pv);
done
/////
I hope this is readable even to a C programmer!
What happens: as written this stores only 45 entries.
When I change the count to 1000 it segfaults during the
storage phase.
OK so here is the Felix binding:
proc JudySLIns: JSLArray * &char * &JError_t * &&word =
"""
if (::std::strlen($2) >= JUDY_SL_MAXLEN) throw "JudySLIns strlen>10000";
*(Word_t**)$4=(Word_t*)JudySLIns($1,(unsigned char*)$2,$3);
""";
There's one more thing to look at: Felix now allows JudySL arrays to contain Felix
pointers as values. The GC uses the follow routine to scan a JudySL array
for such values:
void *JudySL_scanner(collector_t *collector, gc_shape_t *shape, void *pp, unsigned long dyncount, int reclimit)
{
void *p = *(void**)pp;
//printf("Scanning judyL array %p->%p\n", pp, p);
JError_t je;
unsigned char *key = (unsigned char*)::std::malloc(10000); // HACK
*key = 0;
Word_t *pval = 0;
pval = (Word_t*)JudySLFirst(p, key, &je);
while(pval) {
//printf("JudyL scanning p=%s\n",key);
collector->register_pointer((void*)*pval,reclimit);
pval = (Word_t*)JudySLNext(p, key, &je);
}
::std::free(key);
return 0;
}
The collector->register_pointer() function simply checks if the value is a Felix
pointer, if it is, the pointer is "marked" by the GC as reachable and not to be
collected. It is unlikely this code is invoked! I uncommented the diagostic and
it isn't being printed but I include this code for completeness.
The output of the Felix program with loop counter 1000 shows:
779 --> 1728536152 = 1728536152
780 --> 348330048 = 348330048
DUPLICATE
781 --> 342695014 = 342695014
....
816 --> 1595850963 = 1595850963
817 --> 1543867758 = 1543867758
818 --> 1887985652 = 1887985652
Segmentation fault
A duplicate is not likely (pseudo random number generators do not duplicate).
The program "flx_cp" is a sane replacement for unix "cp". This program stores
the source and destination of a wildcarded filecopy command in two judy SL arrays
(src->dst and dst->src) so it can check for overlap before copying. The index is a
null terminated string as required by JudySL, the value is a pointer to a C++ string.
In that program the index values are scrambled exactly as if the keys are overwritting.
It is possible that Erick has screwed up the Judy build. Judy used to be built by the
standard Felix build code, but because of code generation in Judy Makefile
and huge ugly macros to reuse code, I reorganised the code to eliminate the code
generation (by pre-generating the required tables) and copied some files about
to eliminate the need for complex include directives. The generated code is actually
a special indexing table for either 32 or 64 bit Judy. In fact there's no reason to generate
this code since there are exactly two options.. and there even no reason not to build
Judy for BOTH 32 and 64 bit (it can work with BOTH sizes on both 32 and 64 bit machines
with a bit of hacking about to decouple the binary size used for the data structure from
the C types used to manipulate them).
So it is possible the build is screwed up. However I think Judy1 and JudyL work
since they're used extensively by the GC (although .. if they don't it would explain
why some programs crash in the GC .. such as the webserver .. but it seems more
likely to be a bug in the GC).
Bottom line: it looks like a bug in JudySL but Judy has proven to be bug free if built correctly,
just hard to use properly. So it is more likely a bug in my code .. I just can't see it.
On 30/10/2011, at 5:33 AM, Jason E. Aten wrote:
> did you get the JudySLIns figured out?
>
> Here's how I wrap the JLSI macro... which is just
FYI: as you can see by my code I do not use the macros. The confuse values
with lvalues. The function calls make the distinction explicit. Unfortunately it is
the macros that are documented so I have to backtrack the documentation
from the function calls (an extra cognitive layer) and then also consider
the Felix binding .. as well as checking proper use in my application.
>
> void insertkey(const char* key, V value)
> {
>
> PWord_t PValue = 0;
> uint8_t Index[BUFSIZ]; // string to sort.
> strncpy((char*)Index,key,BUFSIZ);
>
> JSLI(
> PValue,
> (_judyS),
> Index); // store string into array
> if (0==PValue) {
> assert(0);
> }
> if ((long)PValue == -1) {
> assert(0);
> }
>
> // was here to diagnose duplicates t_typ's
> // but we never want to overwrite old string without free-ing
> them first,
> // so leave this insert in.
> if (*PValue != 0) {
> assert(0);
> }
>
> ++_size;
> (*((V*)PValue)) = value;
> }
>
>
>
> On Sat, Oct 29, 2011 at 9:21 AM, john skaller
> <sk...@us...> wrote:
>> flx_cp isn't working .. it seems I;m not using JudySLIns correctly:
>>
>> tools/flx_cp web "(.*)" 'xxx\1' --test
>>
>> ////////
>>
>> Consider file download.html
>> Listing ds=d->s
>> Listing sd=s->d
>> subs 1 -> download.html
>> [pre-Ins] Src = web/download.html Dst= xxxdownload.html
>> [post-Ins sd] Src = web/download.html Dst= xxxdownload.html
>> [post-Ins ds] Src = web/download.html Dst= xxxdownload.html
>> Copy web/download.html -> xxxdownload.html
>> Consider file Easy_to_Deploy.fdoc
>> Listing ds=d->s
>> Recorded copy xxxdownload.html <- web/download.html
>> Listing sd=s->d
>> Recorded copy web/download.html -> xxxdownload.html
>> subs 1 -> Easy_to_Deploy.fdoc
>> [pre-Ins] Src = web/Easy_to_Deploy.fdoc Dst= xxxEasy_to_Deploy.fdoc
>> [post-Ins sd] Src = web/Easy_to_Deploy.fdoc Dst= xxxEasy_to_Deploy.fdoc
>> [post-Ins ds] Src = web/Easy_to_Deploy.fdoc Dst= xxxEasy_to_Deploy.fdoc
>> Copy web/Easy_to_Deploy.fdoc -> xxxEasy_to_Deploy.fdoc
>> Consider file Easy_to_Read_and_Write.fdoc
>> Listing ds=d->s
>> Recorded copy xxxEasy_to_Deploy.fdoc <- web/Easy_to_Deploy.fdoc
>> Recorded copy xxxdasy_oad.html <- web/download.html
>> Listing sd=s->d
>> Recorded copy web/asy__to_htmloy.fdoc -> xxxEasy_to_Deploy.fdoc
>> Recorded copy web/asy_loadhtmll -> xxxdownload.html
>> subs 1 -> Easy_to_Read_and_Write.fdoc
>> [pre-Ins] Src = web/Easy_to_Read_and_Write.fdoc Dst= xxxEasy_to_Read_and_Write.fdoc
>> [post-Ins sd] Src = web/Easy_to_Read_and_Write.fdoc Dst= xxxEasy_to_Read_and_Write.fdoc
>> [post-Ins ds] Src = web/Easy_to_Read_and_Write.fdoc Dst= xxxEasy_to_Read_and_Write.fdoc
>> Copy web/Easy_to_Read_and_Write.fdoc -> xxxEasy_to_Read_and_Write.fdoc
>> Consider file Easy_to_Read_and_Write_01.cpp
>> Listing ds=d->s
>> Recorded copy xxxEasy_to_Dead_y.fdoc <- web/Easy_to_Deploy.fdoc
>> Recorded copy xxxEasy_to_Read_and_Write.fdoc <- web/Easy_to_Read_and_Write.fdoc
>> Recorded copy xxxdasy_oad.html <- web/download.html
>> Listing sd=s->d
>> Recorded copy web/asy__to_html_andWritte.fdoc -> xxxEasy_to_Read_and_Write.fdoc
>> Segmentation fault
>> ///////////
>>
>> clearly some overwiting happening ....
>>
>>
>> --
>> john skaller
>> sk...@us...
>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Felix Language" group.
>> To post to this group, send email to fel...@go....
>> To unsubscribe from this group, send email to fel...@go....
>> For more options, visit this group at http://groups.google.com/group/felix-language?hl=en.
>>
>>
--
john skaller
sk...@us...
|
|
From: john s. <sk...@us...> - 2011-10-30 05:31:17
|
On 30/10/2011, at 9:40 AM, john skaller wrote: > Hi, I'm having some problems with JudySL .. not sure what's going on. Well ... isn't this impossible? // program open Judy; x := JSLArray(); var je: JError_t; var pv : &word; var buffer: &char = C_hack::cast[&char] (C_hack::malloc(1000)); for var i in 0 upto 1000 do var j = Cstdlib::rand(); println$ "Rand = " + str j; var s = j.str; println$ "Rand = " + s; var cp = s.cstr; println$ "C string="+ str cp; strncpy(buffer,cp,800); print$ str i + " --> " + str j + " = " + buffer; JudySLIns(x,buffer,&je,&pv); assert not (isNULL pv); print$ " Done " + str i; if C_hack::cast[long] (*pv) != 0l do println "DUPLICATE"; done *pv = C_hack::cast[word] i; println$ " Assigned " + str i; done // tail of output 812 --> 1608776735 = 1608776735 Done 812 Assigned 812 Rand = 1891469415 Rand = 1891469415 C string=1891469415 813 --> 1891469415 = 1891469415 Done 813 Assigned 813 Rand = 726031364 Rand = 726031364 C string=726031364 814 --> 726031364 = 726031364 Done 814 Assigned 814 Rand = 407052494 Rand = 407052494 C string=407052494 815 --> 407052494 = 407052494 Done 815 Assigned 815 Rand = 1595850963 Rand = 1595850963 C string=1595850963 816 --> 1595850963 = 1595850963 Done 816 Assigned 816 Rand = 1543867758 Rand = 1543867758 C string=1543867758 817 --> 1543867758 = 1543867758 Done 817 Assigned 817 Rand = 1887985652 Rand = 1887985652 C string=1887985652 Segmentation fault /// So .. strncpy has valid data but it is segfaulting. The only way this could possibly happen is if the pointer variable buffer got corrupted. -- john skaller sk...@us... |
|
From: john s. <sk...@us...> - 2011-10-31 02:06:56
|
On 30/10/2011, at 9:40 AM, john skaller wrote:
> Hi, I'm having some problems with JudySL .. not sure what's going on.
Hmm .. what am I doing wrong here? This is a simple C program...
#include "Judy.h"
#include <stdio.h>
int main()
{
printf("Judy test\n");
JError_t je;
void *ja = NULL;
Word_t *pv;
char buffer[1000];
int i;
for (i=0; i<1000; ++i) {
sprintf(buffer,"XX %04d abcdefg",i);
pv = (Word_t*)JudySLIns(&ja, buffer, &je);
*pv = i;
printf("Done %s -> %d\n",buffer, i);
}
buffer[0]=0;
pv = (Word_t*)JudySLFirst(ja,buffer,&je);
while(pv)
{
i = (int)*pv;
printf("found %s -> %d\n",buffer, i);
pv = (Word_t*)JudySLNext(ja,buffer,&je);
}
}
Output:
Done XX 0998 abcdefg -> 998
Done XX 0999 abcdefg -> 999
Segmentation fault
--
john skaller
sk...@us...
|
|
From: john s. <sk...@us...> - 2011-10-31 04:04:37
|
On 31/10/2011, at 1:44 PM, John Tromp wrote: > hi John, > >> Hmm .. what am I doing wrong here? This is a simple C program... > > May be a problem with your Judy installation. Yes. That seems likely (since we use our own build script written in Python). > I runs fine on my brand new MacBook Air with > gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) > and judy-1.0.5 in 64 bit mode. > Last 3 lines of output: > found XX 0997 abcdefg -> 997 > found XX 0998 abcdefg -> 998 > found XX 0999 abcdefg -> 999 I have played around with it, and using memset to clear buffer, changing the sprintf to use %016d, %d, or various things makes a huge mess of the keys. Indeed if all the strings are the same length it seems to work. I even got this: found XX 1 -> 0 found XX 2 -> 81 found XX 3 -> 780 found XX 4 -> 117 found XX 5 -> 466 found XX 6 -> 419 found XX 7 -> 444 found XX 8 -> 785 found XX 9 -> 346 (exit here) when memset buffer to all 0 (and no error ..). BTW: ~/felix>gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) I'd sure love to get C++1x for OSX... need LLVM compiler for that though? -- john skaller sk...@us... |
|
From: john s. <sk...@us...> - 2011-10-31 04:33:53
|
On 31/10/2011, at 3:03 PM, john skaller wrote:
>
> On 31/10/2011, at 1:44 PM, John Tromp wrote:
>
>> hi John,
>>
>>> Hmm .. what am I doing wrong here? This is a simple C program...
>>
>> May be a problem with your Judy installation.
>
> Yes. That seems likely (since we use our own build script written in Python).
>
Yep .. its bugged: this code:
macros = [dstname.upper()]
if types.voidp.size == 8:
macros.append('JU_64BIT')
else:
macros.append('JU_32BIT')
sets macros when building Judy1/JudyL but isn't invoked when building JudySL and JudyHS.
So JudySL and HS are built with default which I guess is 32 bits.
--
john skaller
sk...@us...
|
|
From: john s. <sk...@us...> - 2011-11-01 01:37:41
|
On 31/10/2011, at 2:32 PM, john skaller wrote:
>
> On 31/10/2011, at 3:03 PM, john skaller wrote:
>
>>
>> On 31/10/2011, at 1:44 PM, John Tromp wrote:
>>
>>> hi John,
>>>
>>>> Hmm .. what am I doing wrong here? This is a simple C program...
>>>
>>> May be a problem with your Judy installation.
>>
>> Yes. That seems likely (since we use our own build script written in Python).
>>
>
> Yep .. its bugged: this code:
>
> macros = [dstname.upper()]
> if types.voidp.size == 8:
> macros.append('JU_64BIT')
> else:
> macros.append('JU_32BIT')
>
> sets macros when building Judy1/JudyL but isn't invoked when building JudySL and JudyHS.
>
> So JudySL and HS are built with default which I guess is 32 bits.
Fixed!
--
john skaller
sk...@us...
|
|
From: john s. <sk...@us...> - 2011-10-31 15:37:21
|
On 01/11/2011, at 1:13 AM, Doug Baskins wrote: > John: > > My latest version of Judy checks to see if it is being compiled in a > 64 bit environment and sets the JU_64BIT macro. Sorry I did not > do that in the released version. I'm not sure that's a good idea. How are you going to get this right? Note that just because the host machine is 64 bit doesn't mean the target is also 64 bit: for example compiling for iPhone (ARM processor!) on modern Mac (Intel, 64 bit). I wish you'd get rid of the table gen stuff. There are only two sizes in reality, 32 and 64 bit. Why not just commit both to the repository, already generated? The problem is the generator must NOT use the environment size as that of the generated tables. The generator runs on the host machine, the tables may be used on Judy running on a completely different machine. The same applies to endian-ness. > I wish the compilers had a portable > way of testing for a 32/64 bit compile in the code. What? Expect a Standards committee to do something useful? > Good catch John Tromp. I would of never found that one. I suspected it, because I knew Erick changed the Felix build process for Judy from my original one which used modified files, to one which used the authentic originals from sourceforge -- thereby allowing any upgrades to be imported. Also the corruption symptoms suggested it, since I know Judy is reliable if built properly. Thanks everyone for your attention! It remains to get Erick to fix the build script (since I can't figure out how to do it). -- john skaller sk...@us... |
|
From: James D. <jam...@gm...> - 2011-10-31 18:30:16
|
On Sun, Oct 30, 2011 at 9:03 PM, john skaller <sk...@us...> wrote: > > BTW: > > ~/felix>gcc --version > i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) > > > I'd sure love to get C++1x for OSX... need LLVM compiler for that though? AFAIK Apple doesn't play to ship a recent GCC version, so yes, you'd need Clang (the C/C++/... compiler built on the LLVM framework) in order to get more C++11 support, and while Clang's making good progress there it's still somewhat behind GCC in my experience. You could build/install your own GCC 4.6.x on Mac OS X, but it won't be an Apple-supported build. -- James |
|
From: john s. <sk...@us...> - 2011-10-31 21:34:34
|
On 01/11/2011, at 4:30 AM, James Dennett wrote: > > You could build/install your own GCC 4.6.x on Mac OS X, but it won't > be an Apple-supported build. Actually I tried to install a pre-built binary from a HPC crowd, the compiler worked but the library didn't. -- john skaller sk...@us... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X