Symbian Developer Network

   
 

Need help using the forums?
Click here

Home » Symbian Developer Network Forums » Discussion Groups » Symbian C++

Thread: constant data in cpp panics on hardware

Legend
  • Five stars: 251 - 10000 pts
  • Four stars: 101 - 250 pts
  • Three stars: 51 - 100 pts
  • Two stars: 11 - 50 pts
  • One star: 1 - 10 pts
  • No stars: 0 - 0 pts
Helpful Answer (1 pts)
Correct Answer (2 pts)

Permlink Replies: 42 - Pages: 3 [ Previous | 1 2 3 | Next ] - Last Post: 30-Jan-2008 02:04 Last Post By: hamishw
roman

Posts: 144
Registered: 22/02/07
Re: constant data in cpp panics on hardware
Posted: 20-Oct-2007 09:08   in response to: Marcus Groeber in response to: Marcus Groeber
Click to report abuse...   Click to reply to this thread Reply
to be honest we don't use WSD and allowepocdlldata was just to try.

The problem exists on both UIQ3.0 and S60, S60 MR, both of them use the same GCCE compiler. Interestingly enough, a colleague of mine, showed me another code which had const char* const, but was failing only on N95.

I think of perhaps upgrading the compiler to later GCCE version, but not sure how, is there how to?
hamishw

Posts: 2,286
Registered: 11/10/06
Re: constant data in cpp panics on hardware
Posted: 02-Nov-2007 06:40   in response to: Marcus Groeber in response to: Marcus Groeber
Click to report abuse...   Click to reply to this thread Reply
Attachment TESTCODE.zip (11.7 K)
Hi Marcus

Looking at the examples above, the problem is that the compiler is doing what its been told it to do, not what they intended it to do.

   const binds to the thing on its right.

The original definition declares a non-constant array of const char* items. So it's the char* that are const, not the data. As far as the compiler is concerned, you are allowed to change any of these array values because the array isn't constant, as long as it's const char* items that you put in there.

const char * m_sRegionAbbrevList[] = { "NA", "EU", "AF", "AS", "AU", "SA", NULL };


The second form "works" because it is correct if it's the array entries which they wanted constant:

const char * const m_sRegionAbbrevList = { x, y, z };

This declares a constant array of modifiable pointers. So now the data in the array is constant, but any item you pull out of it is a char* so you could write to that address as well. This is unlikely to be useful in user-side, but might be used in kernel-side code, for example to have a constant array of addresses of writeable peripheral registers.

There's obviously something going on that's dependant on whether this data is const, but we can't say precisely what. It would help to know what the panic actually is (kern-exec 3 just means there was an exception - but what sort of exception? Alignment fault? NULL pointer? Page fault?)


One of our base engineers tried the const char* and const char* const forms, the compiler generates identical assembler except that in the first case the array is in writable statics and in the second case it's in const data.


Both forms work, we tried the case with the non-const array on Symbian OS v9.2 and it works just fine (source attached), so it might depend on what the type of the DLL is affecting how it gets initialized (ECOM plugin, perhaps?) or whether they are doing this on an ARM9 where you are trying to share the DLL between a fixed and non-fixed process, or two fixed processes (which might cause problems with writable statics because they can't all share the same DLL because they have different address spaces). I also tried this on Nokia E61 (source attached). Lastly we tried it on Nokia E61, again worked fine... see attached test code.

Lastly we tried a version which dynamically loads the DLL into RAM and that works as well (9.2, ARM11 again).

>>In our case, the error went away by linking statically to an EXE rather than building a DLL - but this appears to be a compiler or linker bug in the GCCE toolchain.

If the code is statically linked then at run time obviously its not DLL WSD, its part of the exe.

The upshot is that there must be more to this than just "constness".  There isn't a lot more we can do to test this without some example code which we can run to demonstrate it. 

So this is "on hold" until someone can provide an example which demonstrates a failure in the WSD implementation.

Regards
H

Marcus Groeber
Re: constant data in cpp panics on hardware
Posted: 02-Nov-2007 12:22   in response to: hamishw in response to: hamishw
Click to report abuse...   Click to reply to this thread Reply
hamishw schrieb:

The upshot is that there must be more to this than just "constness".
There isn't a lot more we can do to test this without some example code
which we can run to demonstrate it.

I am currently trying to track down a (potentially) similar bug in our
own code, this time in an EXE, and occurring when an ARMV5-compiled
static lib is linked with GCCE's ld linker. Again one of the points
where the code goes wrong is suspiciously related to a "const char *
const" array, this time with all the consts in place, but possibly with
only the first element in the array initialized.

The fact that in our case the behaviour changes if we link the same code
to an ARMV5 or a GCCE project seems to point more towards the linker
than the compiler.

At the moment this is just conjecture while we are in the middle of
testing (the mix between two toolchains restricts even the usefulness of
on-device debugging), but I'll keep you updated if we can put our finger
onto something.

ciao marcus
Marcus Groeber
Re: constant data in cpp panics on hardware
Posted: 02-Nov-2007 18:06   in response to: Marcus Groeber in response to: Marcus Groeber
Click to report abuse...   Click to reply to this thread Reply
Marcus Groeber schrieb:

The fact that in our case the behaviour changes if we link the same code
to an ARMV5 or a GCCE project seems to point more towards the linker
than the compiler.

It seems that I am getting a bit closer to our version of the error - I
am not sure if it is related to the one at the start of this thread, but
for us it may be caused by the "relaxing" optimization in "ld" which
folds identical string constants at link time, but (at least for our
ARMV5-compiled library) seems to end up causing incorrect pointers to
some strings in the ".conststring" section.

Of course, the advice is that this combination is not guaranteed to
work, but I am not certain at this point if the bug can only occur with
ARMV5-binaries, or if it could GCCE-only code in some circumstances as
well. So far, I have not seen anything obvious in ARMV5_ABIV2 that would
prevent this from happening there as well.

Sorry, no repro yet, just a hunch...

ciao marcus
mateen_maldar

Posts: 35
Registered: 13/10/06
Re: constant data in cpp panics on hardware
Posted: 02-Nov-2007 18:27   in response to: Marcus Groeber in response to: Marcus Groeber
Click to report abuse...   Click to reply to this thread Reply
Hi Jo stichbury,

This is Mateen Maldar , well i just mailing you and the forum of sdn to know that my problem with the sdn subcription that i have withdrawn many months back.. the problem still persists , i'm tired now of deleting box , i cannot do this any more, like a daily habit of deleting sdn mail every day..

Hope my problem gets closed to be a Christmas for me by end of year... and for my mailbox..

Regards,
Mateen Maldar


Date: Fri, 2 Nov 2007 18:07:54 +0000> From: forums@developer.symbian.com> To: mateen_maldar@hotmail.com> Subject: Watch update: new message in forum Symbian C++ by Guest [1qbK5Y-1u-guX]> > Mateen Maldar,> > The forum "Symbian C++", which you have flagged for email nofication, was updated on 02-Nov-2007 18:06:40 by Guest.> > Guest posted the following message:
roman

Posts: 144
Registered: 22/02/07
Re: constant data in cpp panics on hardware
Posted: 02-Nov-2007 22:54   in response to: Marcus Groeber in response to: Marcus Groeber
Click to report abuse...   Click to reply to this thread Reply
we use Os optimization in our code and we have switched on char* to be signed. Will look into finding answers to questions Hamish raised in previous posts.
antony

Posts: 179
Registered: 30/01/07
Re: constant data in cpp panics on hardware
Posted: 03-Nov-2007 16:37   in response to: roman in response to: roman
Click to report abuse...   Click to reply to this thread Reply
Hi,

In response to a post higher up the thread about FAQing WSD -- you may find "Essential Idioms" -> "Static data" in the SDL.

Cheers,
Antony
hamishw

Posts: 2,286
Registered: 11/10/06
Re: constant data in cpp panics on hardware
Posted: 05-Nov-2007 00:57   in response to: Marcus Groeber in response to: Marcus Groeber
Click to report abuse...   Click to reply to this thread Reply
Hi Marcus

Thanks for the information.
If you see the problem in an EXE that would be very disturbing because we've always stated support for WSD in exes. Perhaps I misunderstand?

Looks like you might be heading towards a "reproduceable case". I've set a watch on this thread, but in case I miss it please mail me internally if you discover one.

Regards
Hamish
hamishw

Posts: 2,286
Registered: 11/10/06
Re: constant data in cpp panics on hardware
Posted: 05-Nov-2007 00:59   in response to: antony in response to: antony
Click to report abuse...   Click to reply to this thread Reply
The SDL section appears to be an unattributed  copy of my paper:
http://developer.symbian.com/main/downloads/papers/static_data/SupportForWriteableStaticDataInDLLsv1.1.pdf
(sour grapes :-)

This is currently being updated; the previous version is very anti WSD for reasons of cost - the new version makes clearer distinction that WSD use may be a reasonable tradeoff for 3rd party developers. It *will* also cover the new support provided to allow WSD use in the emulator.

Regards
H
Marcus Groeber
Re: constant data in cpp panics on hardware
Posted: 05-Nov-2007 09:07   in response to: hamishw in response to: hamishw
Click to report abuse...   Click to reply to this thread Reply
hamishw schrieb:

If you see the problem in an EXE that would be very disturbing because
we've always stated support for WSD in exes. Perhaps I misunderstand?

I believe that, luckily, you misunderstand. ;-) For me, this has strayed
away a bit from WSD (as one possible cause for incorrect initialization
of an array of const strings), to obscure problems with const string
arrays in general.

If I understand the binary generated in my case correctly, the problem
occurs with read-only data, and is more related to the way relocs are
computed by the linker when laying out data in the final binary. In this
case, there is nothing the OS loader could do about it at runtime...

We may be chasing multiple bugs here, or (my hope) it is just one, but
so sensitive to the exact content of the binary that changes in string
lists often makes it go away. In this case, the only way to create a
repro might be from fairly complex production code... I'll see what I
can do.

ciao marcus
antony

Posts: 179
Registered: 30/01/07
Re: constant data in cpp panics on hardware
Posted: 05-Nov-2007 19:37   in response to: Marcus Groeber in response to: Marcus Groeber
Click to report abuse...   Click to reply to this thread Reply
Hi,

>> If I understand the binary generated in my case
>> correctly, the problem occurs with read-only data,

Just to confirm -- the code in the original posting to this thread was not read-only data (it was a read-only pointer to read-write data). The compiler would have generated write instructions here.

Antony
sergey_galat

Posts: 6
Registered: 11/12/07
Re: constant data in cpp panics on hardware
Posted: 12-Dec-2007 21:42   in response to: antony in response to: antony
Click to report abuse...   Click to reply to this thread Reply
Hi everyone,

It appears I'm having a problem closely related to the ones being discussed in this thread.
I'm working on a Symbian port (9.2, S60_3rd_FP1)
of a cross-platform project and I'm forced to use WSD in my DLL.
I use default gcce arm toolchain shipped with the SDK (gcc version 3.4.3 (release) (CodeSourcery ARM Q1C 2005)).
It appears that the binary DLL code is generated incorrectly by the toolchain in some cases.
Trying to debug an application which is linked against the DLL using Carbide.c++ 1.2 on my Nokia N93 leads to the following error message:

"Signal 'Exception 0' received. A data abort exception has occurred".

Of course I have "EPOCALLOWDLLDATA" in my mmp file.
Here is the minimal code of DLL I managed to achieve:

TestDll.h

#ifndef __TESTDLL_H__
#define __TESTDLL_H__

#include <e32base.h>
#include <e32std.h>

IMPORT_C void Get();

#endif

TestDll.cpp

#include "TestDll.h"

class CTest : public CBase
{
private:
TTime iStartTime;
};

static CTest test;
static CTest test1;

EXPORT_C void Get()
{
}

Confusing but if you comment out "static CTest test1;" or remove
deriving from CBase or change TTime to int the problem disappears.

It doesn't matter what app do you use to load this dll.
I'd like to attach the whole project (the DLL + a simple helloworld app) but I can't find such option here.

I hope this helps to identify the problem.
Let me know if you need more information.

Thanks,
Sergey.
sergey_galat

Posts: 6
Registered: 11/12/07
Re: constant data in cpp panics on hardware
Posted: 14-Dec-2007 00:03   in response to: sergey_galat in response to: sergey_galat
Click to report abuse...   Click to reply to this thread Reply
It appears my problem is a static instance of a CBase-derived class :-( However I think I was able to reproduce the problem without derivation from CBase... I'll look if I can get a code sample.
hamishw

Posts: 2,286
Registered: 11/10/06
Re: constant data in cpp panics on hardware
Posted: 16-Dec-2007 23:01   in response to: sergey_galat in response to: sergey_galat
Click to report abuse...   Click to reply to this thread Reply
Hi
Please do provide a code sample. At that point I'll take this further. Note that the response may not be instant though as we're coming up to Christmas and I will not be around for a few weeks :-)

Regards
Hamish Willee
Symbian Ltd.
sergey_galat

Posts: 6
Registered: 11/12/07
Re: constant data in cpp panics on hardware
Posted: 21-Jan-2008 14:45   in response to: hamishw in response to: hamishw
Click to report abuse...   Click to reply to this thread Reply
Finally, here it is.
Just build a DLL with the code below and try to load it.

Minimal DLL code:

template <class T>
class TemplateClass
{
public:
~TemplateClass
() {}
};

class TestClass
{
};

static TemplateClass<TestClass> test_var;
static TInt x_var = 10;

Point your RSS reader here for a feed of the latest messages in all forums