-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
ok, now I am working on another issue. I'll let you know when done.
pancake wrote:
> I had similar problems when implementng the callback signature into
> the tokenizer structure. This is because of the different sizes of
> given arguments. I forced (unsigned long long) instead of using off_t
> to avoid problems, and this fix work on my boxes. I'll try with other
> architectures too. (on linux and freebsd on x86 works for me).
>
> I'll try on ARM and cygwin.
>
> Let me know if you find root of the problem.
>
> --pancake
>
>
> git-clone ...
> ./configure
> make
>
> gdb
> open ro /tmp/SPL.nb
> [0x00000000000000]> / ECEC
> 0xBFC77F1000000040 '(null)'
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7e7b7bc in memcpy () from /lib/libc.so.6
> (gdb)
>
>
> , but real programers don't use debuggers! hehe, just kidding and search
> seems to be broken. I'll have a look at it later and will try the night
> tarball.
>
>
> thanks!
>
> pancake wrote:
>
>>Have you tried with the latest nighly tarball? Maybe you missed to
>>git-checkout and run
>>configure again. show me the registers, back trace and such info from
>>gdb if the problem
>>persists.
>
>>Thanks
>
>>--pancake
>
>>On Sat, 07 Apr 2007 13:05:19 +0200
>>esteve espuna <[EMAIL PROTECTED]> wrote:
>
>
>
>>hi for me it segfaults in the callback :
>
>>here:
>> { printf("\e[K"OFF_FMTs" '%s' ", (off_t)where, flag_name);
>> data_print((off_t)where, config.block+(where-config.seek),
>>60, FMT_ASC, MD_BLOCK);
>> }
>
>>tsearch.c line 58. When a hit is found.
>
>
>>Thanks!
>
>>esteve espuna wrote:
>
>
>>>Hi,
>
>>>great!! will have a look at it as soon as possible. By the benchmarking
>>>difference keep in mind that the cost for N searches shouldn't be much
>>>bigger that the cost for one search. The burden for many searches at
>>>once has a payoff in performance.
>
>>>Anyway if I have some time I'll look at it!
>
>
>>>Great work!
>
>
>>>pancake wrote:
>
>
>>>>>I have finally integrated the new search engine into radare.
>>>>>
>>>>>Thanks to esteve for the great search algorithm!
>>>>>
>>>>>This new algorithm is called "binparser" and it's in his first stage
>>>>>of
>>>>>design. The new engine fixes all the tickets in the bug report page
>>>>>and gives more possibilities with a new regexp-like syntax for binary
>>>>>searchs.
>>>>>
>>>>>[0x00000000000000]> /?
>>>>>/x A0 B0 43 ; hex byte pair binary search.
>>>>>/m FF 0F ; Binary mask for search
>>>>>/ \x7FELF ; plain string search (supports \x).
>>>>>/. [file] ; search using the token file rules
>>>>>/r 0,2-10 ; launch range searches 0-10
>>>>>/l ; list all search tokens (%SEARCH[%d])
>>>>>// ; repeat last search
>>>>>
>>>>>Note that the buggy GNU regexps have been removed in pro to avoid
>>>>>buggy
>>>>>results and buggy portability. The /m command to define a MASK for
>>>>>binary
>>>>>strings is not yet implemented , but the rest is fine.
>>>>>
>>>>>You can throw N token searchs at once, so paralel searchs will be
>>>>>faster
>>>>>than serialized ones with the old engine. Search strings are stored in
>>>>>environment variables named %SEARCH[#] where '#' is a number from 0 to
>>>>>N.
>>>>>
>>>>>This is very useful because you can define multiple search strings and
>>>>>throw them by range:
>>>>>
>>>>>/r 0-3,5
>>>>>
>>>>>This command will throw a search for the tokens 0, 1, 2, 3 and 5
>>>>>Use the % command to define the search strings:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>%SEARCH[3] ELF\x01
>>>>>
>>>>>
>>>>>The regexp support is done with [a-z] [0x00-0xFF] , etc... so,
>>>>>remember
>>>>>to scape the '[' and other critical characters. (read the source, no
>>>>>doc yet)
>>>>>
>>>>>I've done some benchmarking on it and these are the results:
>>>>>
>>>>>Time resuls searching a 3 char string inside a file of 60M:
>>>>>
>>>>>old engine:
>>>>>real 0m3.352s
>>>>>user 0m2.973s
>>>>>sys 0m0.377s
>>>>>
>>>>>new engine:
>>>>>real 0m4.956s
>>>>>user 0m4.610s
>>>>>sys 0m0.347s
>>>>>
>>>>>-------------
>>>>>
>>>>>The new engine is a bit slower, but it's ok for me, actually the code
>>>>>is
>>>>>not clean at all, and both search engines are there. So I could
>>>>>probably
>>>>>think on maintain both search engines or just the best one :)
>>>>>
>>>>>The next goal is to implement the 'binary mask'.
>>>>>
>>>>>Hope to documentate all this stuff in the wiki ASAP.
>>>>>
>>>>>
>>>>>--pancake
>>>>>_______________________________________________
>>>>>radare mailing list
>>>>>[email protected]
>>>>>https://lists.nopcode.org/mailman/listinfo/radare
>>>>>
>
>
>>_______________________________________________
>>radare mailing list
>>[email protected]
>>https://lists.nopcode.org/mailman/listinfo/radare
>
>
> _______________________________________________
> radare mailing list
> [email protected]
> https://lists.nopcode.org/mailman/listinfo/radare
>
>
>> --pancake
>>_______________________________________________
>>radare mailing list
>>[email protected]
>>https://lists.nopcode.org/mailman/listinfo/radare
>
>
_______________________________________________
radare mailing list
[email protected]
https://lists.nopcode.org/mailman/listinfo/radare
> _______________________________________________
> radare mailing list
> [email protected]
> https://lists.nopcode.org/mailman/listinfo/radare
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFGF5biHCkwMET/DRYRAil/AJ0R/ycYKg7j+2dOf5Gfjq79CCy5+QCdEuQa
0aWxAXr62BniGN6E3fWVAKY=
=bGLr
-----END PGP SIGNATURE-----
_______________________________________________
radare mailing list
[email protected]
https://lists.nopcode.org/mailman/listinfo/radare
