This is Delphi 10.1 Berlin (probably unpatched).
This code is pretty basic.
This code is not stable.
Why?
procedure TBLEEnumerator.WriteToSubScribedCharacteristic(bs: TArray<byte>);
var
//member ble is an instance of TBluetoothLE
chr: TBluetoothGattCharacteristic;
begin
chr := ble.GetCharacteristic(FBLEGattService, ChooseCharacteristic);
chr.SetValue(bs);
ble.WriteCharacteristic(self.dev, chr);
end;
A few other notes:
This error is when running on Windows, but I intend this code to run also on mobile devices.
This function is called from the Main Thread and is a wrapper around the TBluetoothLE component. The original connection/scan is also handled from the main thread.
It is pretty simple, obviously. TArray is a reference-counted dynamic array.
Here's the call stack when it tanks:
:761d31ce ucrtbase.memcpy + 0x4e
System.Win.BluetoothWinRT.BytesToIBuffer(???,???)
System.Win.BluetoothWinRT.TWinRTBluetoothGattCharacteristic.SetValueToDevice
System.Win.BluetoothWinRT.TWinRTBluetoothLEDevice.DoWriteCharacteristic$52$ActRec.$0$Body
System.Classes.TAnonymousThread.Execute
System.Classes.ThreadProc($7511F40)
System.ThreadWrapper($5A30D30)
:740162c4 KERNEL32.BaseThreadInitThunk + 0x24
:77060fd9 ;
:77060fa4 ;
Here's the deal. This is a BUG in the Embarcadero Libraries. Yes, Yet another bug that they will probably never fix.
Here's how to fix it for yourself:
copy System.Win.BluetoothWinRT.pas to your project directory or some other path used by the project.
open the file in the IDE.
Search for "BytestoIBuffer".
Remove the word "const" from the function signature.
Very few people seem to realize this (including the authors of FMX and VCL) but the use of "const" strings and dynamic arrays causes the Win32 compiler to optimize-out the reference count handling for those structures. I don't know if it affects the mobile compilers or the Win64 compiler, but maybe.
The nasty effect of this is that if that string or dynamic array originated from another thread, that other thread might very well decide to destroy that string or dynamic array before the new thread (in this case an anonymous thread created to write-behind the data) is finished working with it.
Removing const from this function fixed the instability.
Related
I am developing this Delhi 2009 app with SQLite database version 3.7.9, accessed by the Zeos components. Started off OK - I can create a DB if none exists, create tables and insert records - the 'normal stuff'. There is a little table that contains serial params for a connection to some old equipments and the serial comms handler needs to be informed of connection parameter changes, but the Zeos components do not support events on SQLite.
I looked at the SQLite API and there is a 'Data change notification callback', so I set about making this happen. The setup prototype is:
void *sqlite3_update_hook(
sqlite3*,
void(*)(void *,int ,char const *,char const *,sqlite3_int64),
void*
);
So, in Delphi, I imported the DLL call:
function sqlite3_update_hook(pDB:pointer;pCallback:pointer;aux:pointer): pointer; stdcall;
..
function sqlite3_update_hook; external 'sqlite3.dll' name 'sqlite3_update_hook';
..and declared an empty callback for testing:
function DBcallback(aux:pointer;CBtype:integer;CBdatabaseName:PChar;CBtableName:PChar;CBrowID:Int64):pointer; stdcall;
begin
end;
..and called the setup:
sqlite3_update_hook(SQLiteHandle,#DBcallback,dmOilmon);
SQLiteHandle is the sqlite3* pointer for the database as retrieved from the driver after connection. dmOilmon is the DataModule instance so that, when working correctly, I can call some method from the callback, (yes, I know callback is in an unknown thread - I can deal with that OK, I'll just be signaling semaphores).
Good news: when I ran the app, the DBcallback was called, aparrently successfully, upon the first insert. Bad news: some little time later, the app blew up with 'Too many exceptions', and usually a CPU window full of '??', (the occasional alternative was system death and a reboot - Vista Ultimate 64). Breaking in the callback, aux, CBtype and CBrowID were all as expected but the debugger tooltip showed the CBdatabaseName / CBtableName PChars to be pointing at a string of Chinese characters..
I tried to trace where the callback is called from - the call chain passes through in the Zeos driver code, for some reason. Breaking there and stepping through, I checked the stack pointer and it's the same before and after the callback.
So, I set up the 'empty' callback, the callback gets called at the expected point but with a coupe of dodgy-looking parameters, the callback returns to whence it came with the SP correct. I seem to have done everything right, but... :((
Has anyone seen this, (or fixed it even:)?
Can you suggest a mechanism whereby an aparrently successful callback can pesuade an app to later generate recursive exceptions?
Does anyone have any suggestions for further debugging?
Rgds,
Martin
You have the problems with correct translation of SQLite header to Delphi and with linking:
Not stdcall, but must be cdecl.
Your function DBcallback must be a procedure. Because void(*)(...) is a pointer to C function returning void.
Not PChar, but must be PAnsiChar. For non-Unicode Delphi's it may be not important, for Unicode Delphi's, it is only a correct translation.
You are using compile-time dynamic linking (external 'sqlite3.dll' ...) to sqlite3.dll. But ZeosLib uses run-time dynamic linking (LoadLibrary & GetProcAddress). That may lead to "DLL hell" issue, when your EXE loads one sqlite3.dll, and ZeosLib plans to load another sqlite3.dll.
I am not sure how to track down the following crash:
It happens when Unloading a Designtime Package that is used in-house at my company. It is our code, thus it is our bug to fix, not a third party component vendor problem.
It apppears that a thread is involved, but since it happens in the Function ThreadProc in Classes.pas, I'm guessing it's a bare System/RTL thread without even a TThread class wrapper that I should be searching for in our code. (Question Part A: Is that so?)
The call stack contains none of my code, only the IDE itself, and the base function in the call stack is ntdll.RtlInitializeExceptionChain.
call stack example of an access violation in some TThread.Execute method that shows that the debugger gives no details on WHICH thread is involved:
:7599b9bc KERNELBASE.RaiseException + 0x58
:516b4965 ; c:\program files (x86)\embarcadero\rad studio\8.0\bin\exceptiondiag150.bpl
:5003b058 NotifyNonDelphiException + $1C
:77be6a8b ; ntdll.dll
:77bb0143 ntdll.KiUserExceptionDispatcher + 0xf
rtl.Classes.ThreadProc($CB9ED70)
rtl.System.ThreadWrapper($403E910)
:75fb339a kernel32.BaseThreadInitThunk + 0x12
:77bd9ed2 ntdll.RtlInitializeExceptionChain + 0x63
:77bd9ea5 ntdll.RtlInitializeExceptionChain + 0x36
When I try to view thread info, the second Delphi IDE that is my target executable, itself crashes, but I am able to continue to view information in my delphi debug host instance.
I am aware of techniques for debugging designtime packages, and I am using said techniques. That is, I have a first copy of delphi (BDS.exe) launching a second copy, because the package project, has set in its Run Parameters, in the Host Application edit box the main bds.exe for Delphi XE. (C:\Program Files (x86)\Embarcadero\RAD Studio\8.0\bin\bds.exe). Thus when I run my package in debug mode, it loads itself into the Delphi IDE.
Question part B is: What is the best place to set a breakpoint so I can see non-TThread threads, as well as TThread-based threads being created? If there is no way to set a breakpoint, then how about an alternative means of finding what code is creating threads?
Update: I have found that setting a breakpoint in the line that reads Thread.Execute, in function ThreadProc, in Classes.pas, gets me a breakpoint hit on each TThread startup. That is enough to find threads started by a designtime or runtime package from its initialization section, but I'm hoping there exists an even lower level way to do this.
I debugged the designtime package crash in the following manner:
As already noted above, set up Delphi to run itself, using Run Parameters, in the Host Application, the path is c:\path-to-delphi-install\bin\bds.exe.
Set a breakpoint in the line in function ThreadProc in System.pas.
Open windows.pas, and around line 30,000-33,000 there is a line like this:
function CreateThread; external kernel32 name 'CreateThread';
Set a breakpoint on the line above with F8. Now when anything in the code being debugged invokes that Win32 function, whether via TThread or not, you'll get a breakpoint.
I have written my own DBX 4 in Delphi 2010 for Firebird database. The driver is a dynalink driver and it works fine with TSQLConnection.
Recently, I try to use the DataExplorer.exe released with Delphi 2010 and encounter error:
"Attempted to read or write protected memory.
This is often an indication that other memory is corrupt".
After trace the source code, I found the following export method may be the cause of the problem:
function DBXLoader_GetDriver(Count: TInt32; Names, Values: TWideStringArray;
ErrorMessage: TDBXWideStringBuilder; out pDriver: TDBXDriverHandle):
TDBXErrorCode; stdcall;
When debugging this method, the Names and Values parameter contain corrupted value. I don't know what cause the problem. Perhaps there is some memory manager problem with DataExplorer.exe (.net issue?)
After some trial and error, I attempt to change the method to as follow:
type
TWideStringArray2 = array of PChar;
function DBXLoader_GetDriver(Count: TInt32; Names, Values: TWideStringArray2;
ErrorMessage: TDBXWideStringBuilder; out pDriver: TDBXDriverHandle):
TDBXErrorCode; stdcall;
This time, the error is gone and soon after it exit this method, the same error raise again
"Attempted to read or write protected memory.
This is often an indication that other memory is corrupt".
Do you have any ideas what could the the cause of the problem?
Looks like you have some memory allocation problems. Are you using SimpleShareMem eventualy?
http://docwiki.embarcadero.com/CodeExamples/en/SimpleShareMem_Sample - describes how to use it.
http://www.codexterity.com/memmgr.htm - also contains some insights on memory allocation but with older approachi using FastSharemem module.
FAstMM reports a memoryleak from a TIdCriticalSection in IdStack.pas. I understand this is a intentional leak, that is documented in the code.
What I do not understand, is why IdStack is included in my project. How can I find out what unit pulls it in?
Is there a way of excluding this leak from the report, using the version of fastmm that comes with delphi 2007?
UPDATE:
Is there a way of finding all the pas-files included in a build?
The Delphi FastMM memory manager provides a method
function RegisterExpectedMemoryLeak(P: Pointer): boolean;
So, if you've found the unit and it turns out that you cannot remove it, you can use this method to supress a memory leak warning.
All Indy units have an 'Id' prefix, so check if you have any of those in your uses clauses.
Another way might be to place a breakpoint in TIdStack.create(). Eventually, the guilty one will show up in the call stack.
There's a lot about this on the 'net, although it is scattered. It alo depends on whether you are using Indy 9 (with D7) or later. It's plauged me too. For Indy 9 I did the following in IdComponent.pas:
initialization
GStackCriticalSection := TCriticalSection.Create;
// BJF Starts
//RegisterExpectedMemoryLeak(GStackCriticalSection);
// BJF Ends
finalization
// Dont Free. If shutdown is from another Init section, it can cause GPF when stack
// tries to access it. App will kill it off anyways, so just let it leak
// BJF has removed comments
FreeAndNil(GStackCriticalSection);
end.
But note that you must put a path to the Indy source in the library path. I believe that Indy 10 is fixed in this respect.
Brian
Look at Uses in your .dpr
Use cnPack (cnPack.org) and select 'Uses Cleaner' to remove units not referenced
I'm a member in a team that use Delphi 2007 for a larger application and we suspect heap corruption because sometimes there are strange bugs that have no other explanation.
I believe that the Rangechecking option for the compiler is only for arrays. I want a tool that give an exception or log when there is a write on a memory address that is not allocated by the application.
Regards
EDIT: The error is of type:
Error: Access violation at address 00404E78 in module 'BoatLogisticsAMCAttracsServer.exe'. Read of address FFFFFFDD
EDIT2: Thanks for all suggestions. Unfortunately I think that the solution is deeper than that. We use a patched version of Bold for Delphi as we own the source. Probably there are some errors introduced in the Bold framwork. Yes we have a log with callstacks that are handled by JCL and also trace messages. So a callstack with the exception can lock like this:
20091210 16:02:29 (2356) [EXCEPTION] Raised EBold: Failed to derive ServerSession.mayDropSession: Boolean
OCL expression: not active and not idle and timeout and (ApplicationKernel.allinstances->first.CurrentSession <> self)
Error: Access violation at address 00404E78 in module 'BoatLogisticsAMCAttracsServer.exe'. Read of address FFFFFFDD. At Location BoldSystem.TBoldMember.CalculateDerivedMemberWithExpression (BoldSystem.pas:4016)
Inner Exception Raised EBold: Failed to derive ServerSession.mayDropSession: Boolean
OCL expression: not active and not idle and timeout and (ApplicationKernel.allinstances->first.CurrentSession <> self)
Error: Access violation at address 00404E78 in module 'BoatLogisticsAMCAttracsServer.exe'. Read of address FFFFFFDD. At Location BoldSystem.TBoldMember.CalculateDerivedMemberWithExpression (BoldSystem.pas:4016)
Inner Exception Call Stack:
[00] System.TObject.InheritsFrom (sys\system.pas:9237)
Call Stack:
[00] BoldSystem.TBoldMember.CalculateDerivedMemberWithExpression (BoldSystem.pas:4016)
[01] BoldSystem.TBoldMember.DeriveMember (BoldSystem.pas:3846)
[02] BoldSystem.TBoldMemberDeriver.DoDeriveAndSubscribe (BoldSystem.pas:7491)
[03] BoldDeriver.TBoldAbstractDeriver.DeriveAndSubscribe (BoldDeriver.pas:180)
[04] BoldDeriver.TBoldAbstractDeriver.SetDeriverState (BoldDeriver.pas:262)
[05] BoldDeriver.TBoldAbstractDeriver.Derive (BoldDeriver.pas:117)
[06] BoldDeriver.TBoldAbstractDeriver.EnsureCurrent (BoldDeriver.pas:196)
[07] BoldSystem.TBoldMember.EnsureContentsCurrent (BoldSystem.pas:4245)
[08] BoldSystem.TBoldAttribute.EnsureNotNull (BoldSystem.pas:4813)
[09] BoldAttributes.TBABoolean.GetAsBoolean (BoldAttributes.pas:3069)
[10] BusinessClasses.TLogonSession._GetMayDropSession (code\BusinessClasses.pas:31854)
[11] DMAttracsTimers.TAttracsTimerDataModule.RemoveDanglingLogonSessions (code\DMAttracsTimers.pas:237)
[12] DMAttracsTimers.TAttracsTimerDataModule.UpdateServerTimeOnTimerTrig (code\DMAttracsTimers.pas:482)
[13] DMAttracsTimers.TAttracsTimerDataModule.TimerKernelWork (code\DMAttracsTimers.pas:551)
[14] DMAttracsTimers.TAttracsTimerDataModule.AttracsTimerTimer (code\DMAttracsTimers.pas:600)
[15] ExtCtrls.TTimer.Timer (ExtCtrls.pas:2281)
[16] Classes.StdWndProc (common\Classes.pas:11583)
The inner exception part is the callstack at the moment an exception is reraised.
EDIT3: The theory right now is that the Virtual Memory Table (VMT) is somehow broken. When this happen there is no indication of it. Only when a method is called an exception is raised (ALWAYS on address FFFFFFDD, -35 decimal) but then it is too late. You don't know the real cause for the error. Any hint of how to catch a bug like this is really appreciated!!! We have tried with SafeMM, but the problem is that the memory consumption is too high even when the 3 GB flag is used. So now I try to give a bounty to the SO community :)
EDIT4: One hint is that according the log there is often (or even always) another exception before this. It can be for example optimistic locking in the database. We have tried to raise exceptions by force but in test environment it just works fine.
EDIT5: Story continues... I did a search on the logs for the last 30 days now. The result:
"Read of address FFFFFFDB" 0
"Read of address FFFFFFDC" 24
"Read of address FFFFFFDD" 270
"Read of address FFFFFFDE" 22
"Read of address FFFFFFDF" 7
"Read of address FFFFFFE0" 20
"Read of address FFFFFFE1" 0
So the current theory is that an enum (there is a lots in Bold) overwrite a pointer. I got 5 hits with different address above. It could mean that the enum holds 5 values where the second one is most used. If there is an exception a rollback should occur for the database and Boldobjects should be destroyed. Maybe there is a chance that not everything is destroyed and a enum still can write to an address location. If this is true maybe it is possible to search the code by a regexpr for an enum with 5 values ?
EDIT6: To summarize, no there is no solution to the problem yet. I realize that I may mislead you a bit with the callstack. Yes there are a timer in that but there are other callstacks without a timer. Sorry for that. But there are 2 common factors.
An exception with Read of address FFFFFFxx.
Top of callstack is System.TObject.InheritsFrom (sys\system.pas:9237)
This convince me that VilleK best describe the problem.
I'm also convinced that the problem is somewhere in the Bold framework.
But the BIG question is, how can problems like this be solved ?
It is not enough to have an Assert like VilleK suggest as the damage has already happened and the callstack is gone at that moment. So to describe my view of what may cause the error:
Somewhere a pointer is assigned a bad value 1, but it can be also 0, 2, 3 etc.
An object is assigned to that pointer.
There is method call in the objects baseclass. This cause method TObject.InheritsForm to be called and an exception appear on address FFFFFFDD.
Those 3 events can be together in the code but they may also be used much later. I think this is true for the last method call.
EDIT7: We work closely with the the author of Bold Jan Norden and he recently found a bug in the OCL-evaluator in Bold framework. When this was fixed these kinds of exceptions decreased a lot but they still occasionally come. But it is a big relief that this is almost solved.
You write that you want there to be an exception if
there is a write on a memory address that is not allocated by the application
but that happens anyway, both the hardware and the OS make sure of that.
If you mean you want to check for invalid memory writes in your application's allocated address range, then there is only so much you can do. You should use FastMM4, and use it with its most verbose and paranoid settings in debug mode of your application. This will catch a lot of invalid writes, accesses to already released memory and such, but it can't catch everything. Consider a dangling pointer that points to another writeable memory location (like the middle of a large string or array of float values) - writing to it will succeed, and it will trash other data, but there's no way for the memory manager to catch such access.
I don't have a solution but there are some clues about that particular error message.
System.TObject.InheritsFrom subtracts the constant vmtParent from the Self-pointer (the class) to get pointer to the adress of the parent class.
In Delphi 2007 vmtParent is defined:
vmtParent = -36;
So the error $FFFFFFDD (-35) sounds like the class pointer is 1 in this case.
Here is a test case to reproduce it:
procedure TForm1.FormCreate(Sender: TObject);
var
I : integer;
O : tobject;
begin
I := 1;
O := #I;
O.InheritsFrom(TObject);
end;
I've tried it in Delphi 2010 and get 'Read of address FFFFFFD1' because the vmtParent is different between Delphi versions.
The problem is that this happens deep inside the Bold framework so you may have trouble guarding against it in your application code.
You can try this on your objects that are used in the DMAttracsTimers-code (which I assume is your application code):
Assert(Integer(Obj.ClassType)<>1,'Corrupt vmt');
It sounds like you have memory corruption of object instance data.
The VMT itself isn't getting corrupted, FWIW: the VMT is (normally) stored in the executable and the pages that map to it are read-only. Rather, as VilleK says, it looks like the first field of the instance data in your case got overwritten with a 32-bit integer with value 1. This is easy enough to verify: check the instance data of the object whose method call failed, and verify that the first dword is 00000001.
If it is indeed the VMT pointer in the instance data that is being corrupted, here's how I'd find the code that corrupts it:
Make sure there is an automated way to reproduce the issue that doesn't require user input. The issue may be only reproducible on a single machine without reboots between reproductions owing to how Windows may choose to lay out memory.
Reproduce the issue and note the address of the instance data whose memory is corrupted.
Rerun and check the second reproduction: make sure that the address of the instance data that was corrupted in the second run is the same as the address from the first run.
Now, step into a third run, put a 4-byte data breakpoint on the section of memory indicated by the previous two runs. The point is to break on every modification to this memory. At least one break should be the TObject.InitInstance call which fills in the VMT pointer; there may be others related to instance construction, such as in the memory allocator; and in the worst case, the relevant instance data may have been recycled memory from previous instances. To cut down on the amount of stepping needed, make the data breakpoint log the call stack, but not actually break. By checking the call stacks after the virtual call fails, you should be able to find the bad write.
mghie is right of course. (fastmm4 calls the flag fulldebugmode or something like that).
Note that that works usually with barriers just before and after an heap allocation that are regularly checked (on every heapmgr access?).
This has two consequences:
the place where fastmm detects the error might deviate from the spot where it happens
a total random write (not overflow of existing allocation) might not be detected.
So here are some other things to think about:
enable runtime checking
review all your compiler's warnings.
Try to compile with a different delphi version or FPC. Other compilers/rtls/heapmanagers have different layouts, and that could lead to the error being caught easier.
If that all yields nothing, try to simplify the application till it goes away. Then investigate the most recent commented/ifdefed parts.
The first thing I would do is add MadExcept to your application and get a stack traceback that prints out the exact calling tree, which will give you some idea what is going on here. Instead of a random exception and a binary/hex memory address, you need to see a calling tree, with the values of all parameters and local variables from the stack.
If I suspect memory corruption in a structure that is key to my application, I will often write extra code to make tracking this bug possible.
For example, in memory structures (class or record types) can be arranged to have a Magic1:Word at the beginning and a Magic2:Word at the end of each record in memory. An integrity check function can check the integrity of those structures by looking to see for each record Magic1 and Magic2 have not been changed from what they were set to in the constructor. The Destructor would change Magic1 and Magic2 to other values such as $FFFF.
I also would consider adding trace-logging to my application. Trace logging in delphi applications often starts with me declaring a TraceForm form, with a TMemo on there, and the TraceForm.Trace(msg:String) function starts out as "Memo1.Lines.Add(msg)". As my application matures, the trace logging facilities are the way I watch running applications for overall patterns in their behaviour, and misbehaviour. Then, when a "random" crash or memory corruption with "no explanation" happens, I have a trace log to go back through and see what has lead to this particular case.
Sometimes it is not memory corruption but simple basic errors (I forgot to check if X is assigned, then I go dereference it: X.DoSomething(...) that assumes X is assigned, but it isn't.
I Noticed that a timer is in the stack trace.
I have seen a lot of strange errors where the cause was the timer event is fired after the form i free'ed.
The reason is that a timer event cound be put on the message que, and noge get processed brfor the destruction of other components.
One way around that problem is disabling the timer as the first entry in the destroy of the form. After disabling the time call Application.processMessages, so any timer events is processed before destroying the components.
Another way is checking if the form is destroying in the timerevent. (csDestroying in componentstate).
Can you post the sourcecode of this procedure?
BoldSystem.TBoldMember.CalculateDerivedMemberWithExpression
(BoldSystem.pas:4016)
So we can see what's happening on line 4016.
And also the CPU view of this function?
(just set a breakpoint on line 4016 of this procedure and run. And copy+paste the CPU view contents if you hit the breakpoint). So we can see which CPU instruction is at address 00404E78.
Could there be a problem with re-entrant code?
Try putting some guard code around the TTimer event handler code:
procedure TAttracsTimerDataModule.AttracsTimerTimer(ASender: TObject);
begin
if FInTimer then
begin
// Let us know there is a problem or log it to a file, or something.
// Even throw an exception
OutputDebugString('Timer called re-entrantly!');
Exit; //======>
end;
FInTimer := True;
try
// method contents
finally
FInTimer := False;
end;
end;
N#
I think there is another possibility: the timer is fired to check if there are "Dangling Logon Sessions". Then, a call is done on a TLogonSession object to check if it may be dropped (_GetMayDropSession), right? But what if the object is destroyed already? Maybe due to thread safety issues or just a .Free call and not a FreeAndNil call (so a variable is still <> nil) etc etc. In the mean time, other objects are created so the memory gets reused. If you try to acces the variable some time later, you can/will get random errors...
An example:
procedure TForm11.Button1Click(Sender: TObject);
var
c: TComponent;
i: Integer;
p: pointer;
begin
//create
c := TComponent.Create(nil);
//get size and memory
i := c.InstanceSize;
p := Pointer(c);
//destroy component
c.Free;
//this call will succeed, object is gone, but memory still "valid"
c.InheritsFrom(TObject);
//overwrite memory
FillChar(p, i, 1);
//CRASH!
c.InheritsFrom(TObject);
end;
Access violation at address 004619D9 in module 'Project10.exe'. Read of address 01010101.
Isn't the problem that "_GetMayDropSession" is referencing a freed session variable?
I have seen this kind of errors before, in TMS where objects were freed and referenced in an onchange etc (only in some situations it gave errors, very difficult/impossible to reproduce, is fixed now by TMS :-) ). Also with RemObjects sessions I got something similar (due to bad programming bug by myself).
I would try to add a dummy variable to the session class and check for it's value:
public variable iMagicNumber: integer;
constructor create: iMagicNumber := 1234567;
destructor destroy: iMagicNumber := -1;
"other procedures": assert(iMagicNumber = 1234567)