On Thu, Jan 29, 2009 at 6:53 PM, Tommy Gildseth
wrote:
> Thanks a lot. Exceptional response time :D
> Less than 2.5 hours from problem reported, till a patch was made. Don't
> think there's many projects or commercial products that can compete with
> that ;-)
Oh, wait , it still has to go through
Teodor Sigaev wrote:
I reproduced the bug with a help of Grzegorz's point for 64-bit box. So,
patch is attached and I'm going to commit it
Thanks a lot. Exceptional response time :D
Less than 2.5 hours from problem reported, till a patch was made. Don't
think there's many projects or commer
char" issue? Does this affect the old contrib/tsearch2 code?
Checked - No, that was improvement for 8.3 :).
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-general maili
Teodor Sigaev writes:
> Tom Lane wrote:
>> Hmm, seems it's not so much a "64 bit" error as a "signed vs unsigned
>> char" issue?
> Yes, but I don't understand why it worked in 32-bit box.
You were casting to unsigned int. So the offset added to the base
pointer for, say, 255 in the char would
Gregory Stark writes:
> I really think he should just change all the "unsigned int" into "unsigned
> char" and not do the type punning with pointer casts. That's just evil.
Oh, I see. That would work too, but I don't really see that it's a huge
improvement.
What *would* be an improvement IMHO i
Tom Lane writes:
> Gregory Stark writes:
>> Maybe I'm missing something but I don't understand how this fixes the
>> problem.
>> s is a "char*" so type punning it to an unsigned char * before dereferencing
>> it is really the same as casting it to unsigned char directly
>
> No, it isn't. If c
Teodor Sigaev writes:
> Tom Lane wrote:
>> Please try to make the commits in the next eight hours, as we have
>> release wraps scheduled for tonight.
> Minor versions or beta of 8.4?
This is just back-branch update releases. 8.4 beta is still a good
ways off :-(
regards
On Thu, Jan 29, 2009 at 4:06 PM, Gregory Stark wrote:
> Gregory Stark writes:
> Ah, I understand how this fixes the problem. You were casting to unsigned
> *int* not unsigned char so it was sign extending first and then overflowing.
:)
> It still seems to me if you put a few "unsigned" in varia
Gregory Stark writes:
> Teodor Sigaev writes:
>
>> I reproduced the bug with a help of Grzegorz's point for 64-bit box. So,
>> patch
>> is attached and I'm going to commit it
> ...
>
>> !Conf->flagval[(unsigned int) *s] = (unsigned char) val;
> ...
>> !Conf->flagval[*(unsigned char*) s]
To be honest, looking through that file, I am quite worried about few
points. I don't know too much about insights of ispell, but I see few
suspicious things in mkSPNode too.
I generally don't want to get involve in reviewing code for stuff I
don't know, But if Teodor (and Oleg) don't mind, I can
On Thu, 2009-01-29 at 19:00 +0300, Teodor Sigaev wrote:
> > Please try to make the commits in the next eight hours, as we have
> > release wraps scheduled for tonight.
>
> Minor versions or beta of 8.4?
Minor versions.
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gun
Gregory Stark writes:
> Maybe I'm missing something but I don't understand how this fixes the problem.
> s is a "char*" so type punning it to an unsigned char * before dereferencing
> it is really the same as casting it to unsigned char directly
No, it isn't. If char is signed then you'll get qu
Tom Lane wrote:
Teodor Sigaev writes:
I reproduced the bug with a help of Grzegorz's point for 64-bit box.
Hmm, seems it's not so much a "64 bit" error as a "signed vs unsigned
char" issue?
Yes, but I don't understand why it worked in 32-bit box.
Does this affect the old contrib/tsear
Teodor Sigaev writes:
> I reproduced the bug with a help of Grzegorz's point for 64-bit box. So, patch
> is attached and I'm going to commit it
...
> ! Conf->flagval[(unsigned int) *s] = (unsigned char) val;
...
> ! Conf->flagval[*(unsigned char*) s] = (unsigned char) val;
Maybe I'm mis
Teodor Sigaev writes:
> I reproduced the bug with a help of Grzegorz's point for 64-bit box.
Hmm, seems it's not so much a "64 bit" error as a "signed vs unsigned
char" issue? Does this affect the old contrib/tsearch2 code?
Please try to make the commits in the next eight hours, as we have
rele
On Thu, Jan 29, 2009 at 3:32 PM, Teodor Sigaev wrote:
>
>
>> Than I have quite few notes about that function:
>> - affix is not checked on entry, and should be unsigned,
>
> Could be Assert( affix>=0 && affix < Conf->nAffixData )
>
wouldn't that crash pg backend too ?
The structure that this file
On Thu, Jan 29, 2009 at 3:26 PM, Teodor Sigaev wrote:
> I reproduced the bug with a help of Grzegorz's point for 64-bit box. So,
> patch is attached and I'm going to commit it
:)
To be honest, looking through that file, I am quite worried about few
points. I don't know too much about insights of
Than I have quite few notes about that function:
- affix is not checked on entry, and should be unsigned,
Could be Assert( affix>=0 && affix < Conf->nAffixData )
- for sake of safety uint32_t should be used instead of unsigned int,
in the cast
see patch
- there should be some safety limit
I reproduced the bug with a help of Grzegorz's point for 64-bit box. So, patch
is attached and I'm going to commit it
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
*** src/backend/tsearch/
if it's
static uint32
makeCompoundFlags(IspellDict *Conf, int affix)
{
uint32 flag = 0;
char *str = Conf->AffixData[affix];
while (str && *str)
{
flag |= Conf->flagval[(unsigned int) *str];
str++;
}
ret
Teodor Sigaev wrote:
How do I make a backtrace?
- if you have coredump, just execute gdb /PATH1/postgres gdb /PATH2/core
and type bt. Linux doesn't make core by default, so you allow to do it
by ulimit -c unlimited for postgresql user
- connect to db, and attach gdb to backend process: gdb /P
to get coredump:
sudo su - postgres
ulimit -c unlimited
pg_ctl restart
Also, Teodor - mind the fact, that his machine is 64, and you've
tested it on 32bits.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
How do I make a backtrace?
- if you have coredump, just execute gdb /PATH1/postgres gdb /PATH2/core and
type bt. Linux doesn't make core by default, so you allow to do it by ulimit -c
unlimited for postgresql user
- connect to db, and attach gdb to backend process: gdb /PATH1/postgres
BACKEND
I tried without specifying a StopWords-list as well, but same thing happens.
Teodor Sigaev wrote:
Could you provide a backtrace? Do you use unchanged norwegian.stop file?
I'm not able to reproduce the bug - postgres just works.
Tommy Gildseth wrote:
While trying to create a new dictionary for
Yes, originaly I used a customized norwegian.stop-file, but I changed
that to the one that comes with PostgreSQL, and got the same error.
How do I make a backtrace?
Teodor Sigaev wrote:
Could you provide a backtrace? Do you use unchanged norwegian.stop file?
I'm not able to reproduce the bug -
It works on one of my servers:
SELECT version();
version
-
PostgreSQL 8.3.4 on i686-pc-linux-gnu, compiled by GCC cc (GCC) 3.2.3
20030502 (Red
Could you provide a backtrace? Do you use unchanged norwegian.stop file?
I'm not able to reproduce the bug - postgres just works.
Tommy Gildseth wrote:
While trying to create a new dictionary for use with PostgreSQL text
search, I get a segfault. My Postgres version is 8.3.5
--
Teodor Sigaev
Tommy,
I tried your example and didn't find any problem.
My postgresql version is 8.3.3 and I didn't use stopwords, since I don't
have them.
arxiv=# select version();
version
PostgreSQL 8.3.
While trying to create a new dictionary for use with PostgreSQL text
search, I get a segfault. My Postgres version is 8.3.5
The dictionary I use is the "Norwegian Bokmål & Nynorsk (Norway) pack
for OOo 2.x" downloaded from
http://wiki.services.openoffice.org/wiki/Dictionaries#Norwegian_.28Norw
29 matches
Mail list logo
