tkengo / highway Goto Github PK

I would like to point out that identifiers like "_HW_HIGHWAY_H_" and "_HW_LINE_LIST_H_" do not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

I suggest to add the call of the macro "AC_CONFIG_AUX_DIR" to your configuration script so that auxiliary build tools will be stored in a dedicated directory.

I found segmentation fault with following operation.
( "man gcc" is enough large to cause segmentation fault in this case. :) )

$ hw --version
highway version 1.1.0
$ man gcc | hw hoge
Segmentation fault (core dumped)
$ man gcc | wc
  15597  101199  822142

It seems that the "search" function has the out of bounds access to array.
Please check the followings.

Segmentation fault happens in line 424.
The "read_sum" can become larger than NMAX by addition in line 416.

    392 int search(int fd,
    393            const char *pattern,
    394            int pattern_len,
    395            enum file_type t,
    396            match_line_list *match_lines,
    397            int thread_no)
    398 {
    399     char eol = '\n';
    400     size_t line_count = 0;
    401     size_t read_sum = 0;
    402     size_t n = NMAX;
    403     ssize_t read_len;
    404     int buf_offset = 0;
    405     int match_count = 0;
    406     bool do_search = false;
    407     char *buf = (char *)hw_calloc(n + 1, SIZE_OF_CHAR);
    408     char *last_new_line_scan_pos = buf;
    409     char *last_line_end;
    410 
    411     if (!op.use_regex) {
    412         prepare_fjs(pattern, pattern_len, t);
    413     }
    414 
    415     while ((read_len = read(fd, buf + buf_offset, NMAX)) > 0) {
    416         read_sum += read_len;
    417 
    418         // Search end position of the last line in the buffer. We search from the first posi    418 tion
    419         // and end position of the last line.
    420         size_t search_len;
    421         if (read_len < NMAX) {
    422             last_line_end = buf + read_sum;
    423             search_len = read_sum;
    424             buf[read_sum] = eol;
    425         } else {

Thanks for sharing the project, now I want to use hw as ctrlp.vim's user_command, so I need the feature just like ag's -g option, will you support it? or does the latest version of hw support it?

Would you like to add more error handling for return values from functions like the following?

• lseek ⇒ detect_file_type
• pthread_create ⇒ process_terminal

The silver searcher is already great, I stumbled upon your project and wondered what its advantages were over something as developed as the silver searcher (ag).
Is it the UTF-8 support?

$ hw a

Searchable

$ hw hoge

hw(38555,0x7fffe19753c0) malloc: *** malloc_zone_unregister() failed for 0x7fffe196b000

• hard
  macbook pro 2016

• os
  10.12.2

• highway version
  $ hw --version

hw(38648,0x7fffe19753c0) malloc: *** malloc_zone_unregister() failed for 0x7fffe196b000
highway version 1.1.0

I guess that it is inappropriate to perform a predicate check without more data access synchronisation.

When searching a reasonably large directory tree (~8GB, 19M lines of code), using simple pattern matching (no flags) I get segfaults at least half the time.

system:
Darwin 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64

I have seen that no loop is used around a call of the function "pthread_cond_wait".
Would you like to reuse anything from my message on the topic "spurious wakeup"?

I suggest to use the parameters "ACTION-IF-FOUND" and "ACTION-IF-NOT-FOUND" for the macro call "AX_PTHREAD" in your build specification.

hi @tkengo ,now i am using ag,what is the diff between them ,and is there any pissble support ubuntu

I have noticed that the functions "pthread_mutex_lock" and "pthread_mutex_unlock" are called (for the variable "print_mutex") within the implementation of the function "process_terminal" without accessing another shared resource between these calls.
I suggest to reconsider the corresponding lock scope.