taikoo / judyarray Goto Github PK

What steps will reproduce the problem?
1. run `gcc judy64k.c` on Mac 10.5

What is the expected output? What do you see instead?
I expect a successful compilation. Instead, I get a report the file `windows.h` 
cannot be found.

What version of the product are you using? On what operating system?
judy64k.c on Mac OS 10.5

Please provide any additional information below.
The correct solution appears to be to change line #1355 to read: `#if 
defined(__APPLE__) || defined(linux)`

What steps will reproduce the problem?
1. On windows 7, in CodeBlocks ide, create new c console project.
2. Copy contents of the whole judy2a.c and paste to the top of the main.c.
3. Click "Build" button.

What is the expected output? What do you see instead?
see attached image.

What version of the product are you using? On what operating system?


Please provide any additional information below.

What steps will reproduce the problem?
1. Insert a reasonable amount of integers in the judy array. Like 64. With 15 
elements the issue does not happen;

2. Delete an entry in the middle;

3. Look for the entry in the middle using 'judy_strt' (to get the lower bound);

4. Try to assemble the key (using 'judy_key') of the found element.

What is the expected output? What do you see instead?

The expected output is to get the key that I used to insert the entry, however, 
what I get is a garbage value. Moreover, the VS Run-Time check reports a stack 
corruption around the variable used to receive the value of the key.

What version of the product are you using? On what operating system?

The latest commit, from January 2nd 2013.

Please provide any additional information below.

The issue is properly described in the attached file, which is a simple C 
program (only main.c) which describes exactly the step to reproduce the bug. It 
was compiled to Debug x64 using Visual Studio 2012 in Windows 8 x64.

The curious thing is that do the bug does not happen when I run the test 
application (source attached) to use 15 elements, but when I use a larger 
amount (let us say, 64), than I have the bug.

judy64nb.c crashes with some sequences of judy_cell (works fine when same 
(string) keys are entered in different sequence)

Crashes with
Program received signal SIGSEGV, Segmentation fault.
__memmove_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2814

(gdb) bt
#0  __memmove_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2814
#1  0x00000000004058c5 in memmove (__len=<optimized out>, __src=<optimized 
out>, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string3.h:57
#2  judy_cell (judy=0x61a180, buff=0x62aff8 "", buff@entry=0x7fffffffd960 
"andr0id", max=4294897880) at src/judy64nb.c:1298
#3  0x0000000000402389 in main (argc=<optimized out>, argv=<optimized out>) at 
src/shallot.c:276

With some additional printf debugging:
printf ("%p %d %d\n", base, keysize, slot);
0x61a150 8 -1

slot is -1 which never happens on successful runs.

1297     memmove(base, base + keysize, slot * keysize);

I'm not sure if the loop at 1297 is supposed to make slot negative in case it 
doesn't reach "break".
1268     while( slot-- ) {
           ...
1277     }

This small testcase already exhibits the behavior on my system:

#include <stdio.h>
#include "judy64nb.h"

int main (int argc, char *argv[]) {
  void * judy;
  JudySlot *res;
  JudySlot i = 0;

  judy = judy_open (2, 0);
  res = judy_cell (judy, "android", 7);
  *res = i++;
  res = judy_cell (judy, "andr0id", 7); /* crashes here */
  *res = i++;

  judy_close (judy);
  return 0;
}

Changing the insertion order of the strings (first "andr0id", then "android") 
does NOT crash.

Running on x86_64, ubuntu 14.10

What steps will reproduce the problem?
1. cannot embed judyarray inside my project

What is the expected output? What do you see instead?
I'm expecting a file called judy.h with all exported prototype functions, plus 
any typedef struct needed from the outside

What version of the product are you using? On what operating system?
The latest judyarray on Linux debian stable 64bit

Please provide any additional information below.
One could try to extract the needed stuff by himself and create the file ".h", 
but it should be distributed with the project.

Thank you.

Compiling and run the following program with judy64d.c:
<code>
#include <stdio.h>                                                              
#include "judy64d.h"                                                            
int main()                                                                      
{                                                                               
    Judy *j = judy_open(16);                                                    
    judyslot *slot;                                                             
    uchar buf[10];                                                              
    uint len;                                                                   

    *(judy_cell(j, (uchar*)"a", 1))=1;                                          
    *(judy_cell(j, (uchar*)"b", 1))=1;                                          
    slot = judy_strt(j, NULL, 0);                                               
    while (slot) {                                                              
        len = judy_key(j, buf, sizeof(buf));                                    
        printf("%*s(%d)\n", len, buf, len);                                     
        slot = judy_nxt(j);                                                     
    }                                                                           

    judy_close(j);                                                              
    return 0;                                                                   
}
</code>

Expected output is:
<code>
a(1)
b(1)
</code>

Actual output is:
<code>
       a(8)
       b(8)
</code>

There's extra NUL bytes at the end of retrieved key buffers.

I found this issue with judy64d.c in an environment with gcc 4.6.1, Ubuntu 
11.10 on amd64

If you commented one of the judy_cell() calls, the output will be the same as 
expected output.

When creating a judy array, judy_open() didn't initialize JudySeg struct's 
'seg' field (nor will valloc). This will cause judy_close() randomly segfaults 
for freeing invalid pointer.

To fix the bug, simply change the segment in judy_open():
<code>
if ((seg = valloc(JUDY_seg))) {
  seg->next = JUDY_seg;
}
...
</code>
to:
<code>
if ((seg = valloc(JUDY_seg))) {
  seg->seg = NULL;
  seg->next = JUDY_seg;
}
...
</code>