Limits on number of Mouse Macros?

[Helge Rasmussen]

Hi,

yesterday after making some changes to my iFLy 737 setup for Linda, I started getting out of memory errors from FSUIPC.

Here is the log:

********* FSUIPC4, Version 4.714 by Pete Dowson *********

Reading options from "E:\FSim\Microsoft Flight Simulator X\Modules\FSUIPC4.ini"

Trying to connect to SimConnect Acc/SP2 Oct07 ...

User Name="Helge Rasmussen"

User Addr="This is a secret"

FSUIPC4 Key is provided

WideFS7 Key is provided

Running inside FSX on Windows 7 (using SimConnect Acc/SP2 Oct07)

Module base=0E2A0000

Wind smoothing fix is fully installed

DebugStatus=255

2325 System time = 19/07/2011 08:20:02

2325 FLT UNC path = "C:\Users\her\Documents\Flight Simulator X Files\"

2325 FS UNC path = "E:\FSim\Microsoft Flight Simulator X\"

2559 FSUIPC4: bad value from malloc

2559 Memory problems detected! Operations restricted.

7348 LogOptions=00000000 00000001

7348 SimConnect_Open succeeded: waiting to check version okay

7473 VRI port 1 "COM3" failed to open

9392 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0)

9392 Initialising SimConnect data requests now

9392 FSUIPC Menu entry added

9454 C:\Users\her\Documents\Flight Simulator X Files\Default.FLT

9454 E:\FSim\Microsoft Flight Simulator X\SimObjects\Airplanes\C172\Cessna172SP.AIR

19922 System time = 19/07/2011 08:20:19

19922 *** FSUIPC log file being closed

Memory managed: 4 Allocs, 4 Freed

********* FSUIPC Log file closed ***********

After some testing, I figured out that it was the number of mouse macros I have.

There are 7 variants of the i737 and I had 65 macros per variant i.e. 455 macros.

After clearing 6 macros from each variant I ended up with 413 macros, and that worked.

Splitting the macros up in several files seemed to work too.

So my questions are:

What is the number of allowed macros in one file?

Are there any limits on macros across more than one file?

PS. Reason for having all the macros in one file is just not to clutter the Modules folder with more files than necessary.

Regards,

Helge

[Pete Dowson]

yesterday after making some changes to my iFLy 737 setup for Linda, I started getting out of memory errors from FSUIPC.

...

2559 FSUIPC4: bad value from malloc

2559 Memory problems detected! Operations restricted.

...

After some testing, I figured out that it was the number of mouse macros I have.

That's interesting, I've never seen those messages invoked!

The routine which logs that is the one used for all FSUIPC's memory allocations, and it means that when Windows was asked for more memory it said no, it couldn't supply any more! Once that happens, to avoid an infinite loop asking for memory, FSUIPC won't ask for any more. That's what it means by "Operations restricted." It's a pretty crucial error as it would stop a lot of things working properly thereafter.

I wouldn't really expect to see such an error without FS also suffering from memory problems. Maybe it was a transient memory garbage problem but that sounds unlikely if you were able to reproduce it so consistently that you found out how to work-around it.

There are 7 variants of the i737 and I had 65 macros per variant i.e. 455 macros.

After clearing 6 macros from each variant I ended up with 413 macros, and that worked.

Splitting the macros up in several files seemed to work too.

Why does each variant of the same 737NG need a completely separate set of 65 macros? I don't understand things like that. A 737NG is a 737NG -- the cockpit is mostly the same across them all. The small variations you can get are usually customer options, but they are mostly ones of presentation, or the provision or absence of a particular switch or button.

Having extremely large macro files isn't efficient in any case.

What is the number of allowed macros in one file?

There's a limit imposed internally of 999, but you didn't hit that. The limit would merely cause excess macros to be inaccessible because they wouldn't be tabulated.

Are there any limits on macros across more than one file?

There's a maximum number of macro files, but i think that's only imposed by the size of the Macro file list itself -- up to 32k.characters. So there can be more with shorter names.

PS. Reason for having all the macros in one file is just not to clutter the Modules folder with more files than necessary.

Maybe, but there's an efficiency balance between larger files on the one hand and multiple files on the other. I wouldn't know how to compute it though.

I must admit that most of the facilities in FSUIPC were designed with "reasonable use" in mind. These facilities probably aren't robust enough for mass industrial use. I've always striven for efficiency and performance so take the simplest most compact designs that work rather than try to cater for the ultimate and in so doing potentially wreck performance for everyone else.

Anyway, I'm very curious as to how that memory error arose without any other nasty memory problems in FS too. I'd like to investigate. I could try adding extra logging in the memory allocation routine, but i think it might be quicker if I could try reproducing the error here. Do you think you could send me the file(s) which cause the problem for me to test here? ZIP and send to petedowson@btconnect.com. Thanks.

Regards

Pete

[Helge Rasmussen]

I have mailed you the macro file. Just place it in your Modules directory.

I do agree that its a bit exorbitant with that many macros, but I haven't been able to find another way to control the iFly, and it works (well... worked), so all was good.

I have no idea why the iFly developers did it the way they did. There are different .gau files for each plane variant, and there are 7 variants, that's why I had 7*65 macros.

The system's memory is not corrupted as I can run other stuff while in this situation, the meory system of the FS process might be though. When I click ok on the message box that pops up, then the FSX initial screen shows up, and when I click on that, FSX loads and shows the initial scenery and aircraft, then promptly crashes.

Whether this is because FSUIPC is in a bad state at this point, or whether the FS process memory is corrupted I don't know.

Helge

[Pete Dowson]

I have mailed you the macro file. Just place it in your Modules directory.

Thanks! It might be tomorrow before I get to it. Things are piling up a bit! ;-)

I have no idea why the iFly developers did it the way they did. There are different .gau files for each plane variant, and there are 7 variants, that's why I had 7*65 macros.

Ouch!

The system's memory is not corrupted as I can run other stuff while in this situation, the meory system of the FS process might be though.

Yes. No matter how much real memory you have, a 32-bit program like FSX is limited -- 3Gb. We're talking "virtual memory" in any case., the process virtual memory is 4Gb max for a 32-bit process. Other processes might still have most of theirs available even if FSX's process is stuffed.

Regards

Pete

[Pete Dowson]

I have mailed you the macro file. Just place it in your Modules directory.

That was very useful. Thanks.

it was a bug. I was using a short integer (16 bit) for a size value for internal storage based on the size of the MCRO file, and yours computed at over 32k, which made it look negative in a signed 16-bit word. That got expanded to a HUGE positive number when fed to the memory allocation routine ... bang!

It'll be fixed in forthcoming updates for FSUIPC3 and FSUIPC4, probably Thursday but maybe tomorrow.

Regards

Pete

[Helge Rasmussen]

Glad to have been of assistance :)

Helge

[Pete Dowson]

Glad to have been of assistance :)

The fix is in these versions:

FSUIPC 3.997f

FSUIPC 4.716

Although I know you have a work-around in use now.

Regards

Pete