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
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFGF42VHCkwMET/DRYRAr1jAJ9M+QmamY2zNqLnTiNZHA/8DX1CkACfVPfU
> J3TYi/tV0IeeCBdwRYCP1Yg=
> =MUdb
> -----END PGP SIGNATURE-----
> _______________________________________________
> radare mailing list
> [email protected]
> https://lists.nopcode.org/mailman/listinfo/radare
>
>
_______________________________________________
radare mailing list
[email protected]
https://lists.nopcode.org/mailman/listinfo/radare
