Recent

Author Topic: Lazarus crashes at "Post" after update from 1.8.2 to 2.0.10 and 2.2  (Read 884 times)

xenon1

  • Newbie
  • Posts: 1
I just want to report: After updating Lazarus from 1.8.2 to 2.0.10 (and again after I updated to 2.2, hoping the problem would go away), it regularly crashed at the database command "Post" when posting a string. (Commands: Edit; FieldByName('xxx').AsString := 'xxxx'; Post).

It took me two days to figure out why: Lazarus had given the field length ("Size") as something like 1000 or even 1024, as I finally found in the Object Inspector, although the field length of the database field (firebird) was only 255 [varchar(255)]. When I set the field length in the Object Inspector to the right value (Size: 255) everything went fine.

My operationg system during this problem: MX Linus 21.1., based on Debian 11 (bullseye).

I was surprised that nobody had reported a similar problem on the Internet, as Lazarus 2.0.10 has been released some time ago. I cannot imagine to be the first person to have experienced this. Whatever, I post this here so that someone else might not have to search days for a solution.

I do not know if this counts as an official bug, and I would not know where to report it anyway.

« Last Edit: June 21, 2022, 07:01:13 pm by xenon1 »

MarkMLl

  • Hero Member
  • *****
  • Posts: 5130
Re: Lazarus crashes at "Post" after update from 1.8.2 to 2.0.10 and 2.2
« Reply #1 on: June 21, 2022, 07:59:24 pm »
I do not know if this counts as an official bug, and I would not know where to report it anyway.

There's a link to the bugtracker at the left of the forum page, i.e. somewhere

<===== OVER THERE :-)

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

af0815

  • Hero Member
  • *****
  • Posts: 1021
Re: Lazarus crashes at "Post" after update from 1.8.2 to 2.0.10 and 2.2
« Reply #2 on: June 21, 2022, 10:19:01 pm »
I do not know if this counts as an official bug, and I would not know where to report it anyway.
And it is good to have a program/demo code to show this bug. It make it easier for the developer to analyse the bug. Reports with demo code often fixed very fast.
regards
Andreas

bum_bum

  • New Member
  • *
  • Posts: 11
Re: Lazarus crashes at "Post" after update from 1.8.2 to 2.0.10 and 2.2
« Reply #3 on: August 03, 2022, 02:03:30 pm »
It took me two days to figure out why: Lazarus had given the field length ("Size") as something like 1000 or even 1024, as I finally found in the Object Inspector, although the field length of the database field (firebird) was only 255 [varchar(255)]. When I set the field length in the Object Inspector to the right value (Size: 255) everything went fine.
Maybe the problem is related to the encoding? In UNICODE, a character can take 4 bytes, then 255 characters will be 1020 bytes long.

Thaddy

  • Hero Member
  • *****
  • Posts: 11902
Re: Lazarus crashes at "Post" after update from 1.8.2 to 2.0.10 and 2.2
« Reply #4 on: August 03, 2022, 03:03:13 pm »
How much is 256 X 4 ?
.... It is NOT 1020, but

1024

But you are correct that you advise is to reserve 4 per byte in all cases except strict Ansi or shortstring.

My other advice would be to do everything on a network in BYTES and not any string type.
« Last Edit: August 03, 2022, 03:06:03 pm by Thaddy »
Black themes should be banned.

bum_bum

  • New Member
  • *
  • Posts: 11
Re: Lazarus crashes at "Post" after update from 1.8.2 to 2.0.10 and 2.2
« Reply #5 on: August 03, 2022, 04:35:43 pm »
How much is 256 X 4 ?
.... It is NOT 1020, but

1024
In the original message 255, not 256. Look carefully...

Thaddy

  • Hero Member
  • *****
  • Posts: 11902
Re: Lazarus crashes at "Post" after update from 1.8.2 to 2.0.10 and 2.2
« Reply #6 on: August 03, 2022, 08:43:43 pm »
the byte range is 0..255 which makes 256. And that is what you need especially when streaming data.
Programmers count from zero.
Really silly. I thought BASIC programmers had by now disappeared. (except from me and a couple of even older archaeological finds   O:-) )

If you want to stream, plz preserve ALL data and do not throw away anything (like 4 bits per package, which will screw you up).
With most - but not all - CPU's you want to stick to a power of two, which is usual CPU register width or an exact fraction of it.
1024 is a power of two, 1020 is error.

For educational purposes: https://en.wikipedia.org/wiki/Power_of_two
Mind the value of n....
« Last Edit: August 03, 2022, 09:03:01 pm by Thaddy »
Black themes should be banned.

MarkMLl

  • Hero Member
  • *****
  • Posts: 5130
Re: Lazarus crashes at "Post" after update from 1.8.2 to 2.0.10 and 2.2
« Reply #7 on: August 03, 2022, 09:39:27 pm »
the byte range is 0..255 which makes 256. And that is what you need especially when streaming data.
Programmers count from zero.

SQL doesn't: varchar(255) has a maximum length of 255.

I thought people who assumed that all languages behaved like C had by now disappeared: particularly in this community.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

korba812

  • Sr. Member
  • ****
  • Posts: 304
Re: Lazarus crashes at "Post" after update from 1.8.2 to 2.0.10 and 2.2
« Reply #8 on: August 04, 2022, 12:31:39 am »
the byte range is 0..255 which makes 256. And that is what you need especially when streaming data.
Programmers count from zero.
Really silly. I thought BASIC programmers had by now disappeared. (except from me and a couple of even older archaeological finds   O:-) )

If you want to stream, plz preserve ALL data and do not throw away anything (like 4 bits per package, which will screw you up).
With most - but not all - CPU's you want to stick to a power of two, which is usual CPU register width or an exact fraction of it.
1024 is a power of two, 1020 is error.

For educational purposes: https://en.wikipedia.org/wiki/Power_of_two
Mind the value of n....

🤦

tonyw

  • Sr. Member
  • ****
  • Posts: 280
    • MWA Software
Re: Lazarus crashes at "Post" after update from 1.8.2 to 2.0.10 and 2.2
« Reply #9 on: August 04, 2022, 04:19:22 pm »
I just want to report: After updating Lazarus from 1.8.2 to 2.0.10 (and again after I updated to 2.2, hoping the problem would go away), it regularly crashed at the database command "Post" when posting a string. (Commands: Edit; FieldByName('xxx').AsString := 'xxxx'; Post).

It took me two days to figure out why: Lazarus had given the field length ("Size") as something like 1000 or even 1024, as I finally found in the Object Inspector, although the field length of the database field (firebird) was only 255 [varchar(255)]. When I set the field length in the Object Inspector to the right value (Size: 255) everything went fine.
<snip>
I'm trying to understand what went wrong here. Firstly, you haven't said which Firebird database driver you are using. Also, have you used to Fields Editor to add the fields to the form, or are you relying on the fields to be dynamically created each time you open the dataset? You have said that you are using "FieldByName" and so I will assume the latter.

In general, all database drivers should  work the same.

When you open a dataset, the FieldDefs collection should be automatically created by the InternalInitFieldDefs method. In IBX, InternalInitFieldDefs runs a query on the database and creates the fielddefs, including the Field Size, from the metadata returned by Firebird. It should be a proper reflection of the database schema - but will also depend upon the connection character set for VarChar. If the field is UTF8 encoded or the connection character set is UTF8 then the field size is four times the character size in order to cope with a maximum length UTF8 string.

The odd thing is that you said the crash occurred when an updated record was posted and that you needed to reduce the field size to make it work.This does not really add up.

Alternatively, if you had used the fields editor, then the field size is saved in the form. When you upgraded, the form would be unchanged and the field size remains unchanged. Maybe, in the previous version you had used a connection character set of UTF8 and hence the long field size and then after upgrade a single byte character set was used (e.g. ANSI). That would explain your problem.


 

TinyPortal © 2005-2018