When opening a TDBF dataset the following exception occures:

"bus error or misaligned data access"

- Leslie -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080512/d9189266/attachment.html

2008/5/11 :

When opening a TDBF dataset the following exception occures: "bus error or misaligned data access"

Can you provide a test program and open a bug report?

Only some dbf files raise the exception. The test app loads the list of dbf files from "DBF_Files.txt."
The first and last files fail to open, but the exception occurs somewhat differently. "angol.dbf" has a primary index, the others do not have any.

Some other notes:

- Changes cannot be posted to the dataset.
- TDBGrid does not uses the preset font when editing.

Regards,
- Leslie -

This might help a little to localize the problem: after removing the index from "angol.dbf" it opens without any problem.

- Leslie -

This might help a little to localize the problem: after removing the index from "angol.dbf" it opens without any problem.

Post a bug report to Free Pascal and attach the test app to it. I never work in the datasets, so I can't help here. This is probably a bug in the TDBf dataset.

In the mean time you can probably try other datasets. TDBf is known to have problems with non-x86 architectures. Maybe someone else can recommend a working dataset for wince, I rarely develop database applications.

Op maandag 12-05-2008 om 21:38 uur [tijdzone -0300], schreef Felipe Monteiro de Carvalho:

Only thing I know, is that most other databases also have problems with wince. First problem is that a lot of sql-based db engines simply don't support WinCE. Second problem are misaligned-data problems in the db-units.

And the only thing I know about alignment, is that it has something to do with starting each 'thing' (word, integer, longint) on an memory-location that could be divided by 2/4/8/whatever.

And since I'm the one who's responsible for the db-unit, that could give some problems.... ;)

I'll have to do some more research and try to get fpc working on a wince emulator or something, sometime, to fix this.

Joost

I probably do not see the depth of the problem, and this seems to be just too easy, but for me this should be done on the compiler level: how about a compiler switch which forces the compiler to "think" as if the "unaligned" keyword was there at the potentially problematic assignments. FPC and Lazarus aims to have a single source for all platforms, and this is broken if you have to change the source for ARM.

Regards

- Leslie -

Felipe,

First of all I would like to congratulate for the great job you guys have done with the WinCE port. You have beaten Borland with all its resources.

Secondly I appreciate your being so responsive. :)

I have written earlier that I would like to help in testing. At the moment I am very short on time, so first I will test only what is required for my project, but I am planning to do some systematic testing later.

Regards,

- Leslie -

Op zaterdag 17-05-2008 om 21:06 uur [tijdzone +0200], schreef :

Is there an "unaligned" keyword? What does it do? And how does it helps me? Remember I told you this:

Joost

Yes.

What does it do? And how does it helps me?

Tell the compiler to access memory location assuming that it is not aligned naturally:

var
   p : plongint;
begin
   getmem(p,8);
   inc(pointer(p),1);
   { seg. faults: }
   p^:=1234;
   { works }
   unaligned(p^):=1234;
   { seg. faults }
   writeln(p^);
   { works }
   writeln(unaligned(p^));
end.

Probably Yuri should answer that. I am not sure, but I think that the problem is that alignment check is very slow. Maybe it could be done with a compiler directive, so that you can choose to have slower, but safer, code, or if you want to manually control all places where potential unalignment may occur and have maximum speed. This is better discussed in the fpc-devel mailling list.