April 21, 2005 at 10:39 am #1504
We have a 25 networked licence of Milti Edit 9.10.04 with around 20 users. There are a few people (around 4, there are 2 that get these issues very regularly) that are having problems when loading files from another application that executed Multi Edit using a command line of “<path to the network>\Mew32.exe -SR <Full path to the file>”.
The problem does not happen every time a file is opened in this way and seems to happen randomly.
The problem is that there are several access violations reported, but the file loads ok, you just have to click through several error dialogs.
I have attached a document with the access violations in the order that they occur.
There is also a problem that sometimes multi edit will load in a way that seems to mess up all of the fonts in the user interface, they all revert to system font, and then the saving issue will happen every time.
The font issue can sometimes be sorted out by quitting multiedit and waitign at least 30 secs before reloading. Is there much server activity required on closing and opening multi edit?
The server is running Win2000.
The client machines that this hapens on are dual processor P4 systems running WinXP SP2.
Other client machines that are fine are a mixture of hyperthreadded and non-hyperthreaded CPU’s and Windows 2000 and Windows XP.
All Clients are running from the same server installation.
I tried to set the affinity of the affinity of the Mew32 process to a single processor but the issues continued.
multiedit problems2.docApril 22, 2005 at 3:57 am #5469
Weird. There is something wrong with no doubts but now I can only suggest few things to try:
– try to remove -SR from MEW command line. It won’t restore previous session and only open the file. If it helps, you can try to start MEW with -SR by hand and left it running. Opens from the app should go to this MEW instance.
I’m suggesting this because encountered few crashes on session restore/switch, too, but never had time to find what caused it.
BTW, the dialogs you posted doesn’t match with your problem description. They’re clear crashes and it is really strange if MEW continues running. Isn’t it possible the app starts multiple MEW instances at once? It would explain it; one instance wins and other crash. Try following:
– reproduce problem until the first error and then examine how many MEW instances (mew32.exe process) are running using Task Manager Processes tab (not Applications) or System Internals’s Process Explorer.
– try to add -NI to MEW command line and maybe you’d see several MEW instances starting.
The next thing you can try is to limit CPU number used by OS. Setting process affinity isn’t enough if problem is caused for example by concurrent network access processing. Please note even if it helps, it wouldn’t be a solution, I’m just interested.
Limit OS to use one cpu only can be done using /ONECPU switch in the boot.ini file. Beware, if you corrupt or destroy this file, OS won’t boot. You can clone the current OS start line by hand like this (from my system):
[code:9fqisuyw]multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="XP one CPU" /fastdetect /noguiboot /onecpu /NoExecute=OptIn
(do NOT copy this line, your probably differs!). The next possibility is to use bootcfg OS supplied utility (try bootcfg /?, I never used it myself). If you don’t know what I’m speaking about, forget it. It needs some previous experience and knowledge in this area.April 22, 2005 at 9:09 am #5471
You were correct, there were 2 processes of mew32.exe being created and the 2nd one was crashing.
It appears to have been solved by forcing the both the application that runs the command line and mew32.exe to run on the same CPU.
It was done using set affinity in the windows task manager – which is a little clumsy as it has to be done every time you start the process!.
I am now looking into how to do this automatically.
So far I have found imagecfg.exe that is part of the windows 2000 resource kit supplement one.
Also there is a Win32 api function to do the same thing that I might look into writing a small program to launch another with the affinity set.
Any other ideas (or do you know of such a program)?
GraemeApril 22, 2005 at 10:55 pm #5473
I don’t think using affinity is a good idea. It doesn’t solve the problem, it can only conceal it or make more rare. The real problem is that application starts more MEW instances at once; from you first log I guess at least 3 because there are two crashed MEW instances.
Also, if you set affinity on the app, you can limit its performance if it is multithreaded app because it means all threads would use one CPU only. Not a big problem for MEW because most work is done in one thread (which can change in the future).
You have two possibilities. First, find and solve the real problem I mentioned above. Second, remove -SR from command line because MEW isn’t prepared to restore session from more instances at once. Without it, one instance should win and other would just post file from command line to it. This should work without crashes.
Also, try what I recommended before. Start MEW with -SR by hand and remove this switch from the app command line. I’d bet you’ll see several files opened at once in previously started instance. I guess the whole problem is app tries to open several files at once using the command line. In this case -SR is quite inappropriate there and has to be removed.April 25, 2005 at 9:12 am #5475
I have tried all of your suggestions to do with the -SR flag.
The -SR flag does not make any difference to the behaviour of Multi Edit in this instance.
After doing the Affinity ‘fix’ we have not had multi edit crash once!
There were definitly only 2 instances of Multi Edit running (Mew32.exe processes).
It does appear to be a timing issue in, perhaps in the code that tries to see if there already exists a copy of multi edit running?
Do you use a mutex to see if you have a running instance? (CreateMutex – borland version of this function)
This works well on our app to avoid multiple instances – we use Borland C++ builder 6.
GraemeApril 25, 2005 at 6:40 pm #5479
it is of course timing issue. Race conditions like this usually appear more easily on multiprocessor machines. That’s why setting affinity can help but it is only a workaround and not the fix. The probability of the problem is decreased but can’t be completely removed. Cooperation between MEW instances has to be improved in the future.
Have you found why is the app starting more MEW instances at once? This is the root of the problem. I don’t say it is illegal but as you can see, it would be better to avoid it.April 26, 2005 at 8:38 am #5482
We use the CreateProcess borland function with the comand line above.
It only ever executes 1 command line at a time – making only 2 instances of Mew32.exe – the original one and the one instantiated using the CreateProcess command.
How could we tell the existing instance of multi edit to open a file at a particular line number withould using the command line arguments to mew32.exe?
Surely running this command line will always start a second mew32.exe process at least until the second one realised that there was already one running and then passed the information to load a file over to it?
Therefore isn’t this issue more to do with the dual processor machines allowing the second mew32.exe instance to somehow get past this check in the code that there is another instance in existance.
We have used the workaround of the processor affinity for a couple of days now and have had no issues.
If you want me to check any updates to Multi Edit for this problem before release just let me know.
GraemeApril 26, 2005 at 4:25 pm #5483
Now I’m not sure if I understand the problem correctly. Who starts the first instance of MEW you described as the original one and how?
Previously I expected the problem is timing i.e. two MEW instances are started in quick succession which causes parallel run on multiprocessor machine. Can you confirm it? Or can you describe exact order of all actions where is MEW involved? Ideally with timing.
Maybe you could post your app here so I can try it on my dual CPU machine.
BTW, what you’re doing is correct if you want open a file in MEW at particular line. New MEW instance tells it to the running one. The next possibility would be to use COM; it should be possible to run a macro this way (I never tried it).April 27, 2005 at 7:38 am #5493
Sorry for the confusion – i just re read my previous posts again!
The order of events is as the following –
– An existing copy of multi-edit is running run by the command mew32.exe -SR
– After a user determined amount of time (i.e. not immediatly after starting the main mew32 instance) the application will use the CreateProcess command with the command line <path>mew32.exe -SR /L 300
This fires off another process of Mew32 which should realise that another one exists and then use that instance to load the file – but it sometimes seems to fail to so this and gives access violations.
Attached is a simple program written in c++ builder 6 that still produces the error when the steps above are followed.
It took about 4 attempts loading different files to get it to happen.
You can then stop it happening by using task manage to set the processor affinity of both of the processes to the same CPU (we always use the first one)
mew32 issue.zipApril 27, 2005 at 10:56 pm #5494
OK, few more questions:
– what crashes, the first MEW instance or the one started from your app?
– how much time elapses between individual attempts to load different files from your app this way (the way is correct)?
– does it crash sometimes on the first attempt?
– is it reproducible if you wait say at least 10 sec between individual attempts?
I’m sorry but your app doesn’t work for me; it ony creates a taskbar entry and no visible window can be displayed. I don’t have Borland C++ builder and had to download support DLLs so maybe there is a version mismatch.April 28, 2005 at 7:37 am #5495
I have attached a statically linked version of the program.
In answer to your questions:
– The one started from our app.
– It can vary from 1 second to 1hour with it failing (or not – it does not seem to be dependent on how quickly you start run the command line after each time)
– I think so (Although it doesn’t crash if you have no Mew32.exe processes runing to start with)
Project1.zipApril 28, 2005 at 10:41 pm #5499
Well, you destroyed my theory Anyway, it is interesting problem and I’ll try to examine it when have time. Maybe I’ll send you something for testing, later. For now use the affinity workaround.
Yet another question: have you tried to reproduce problem with MEW installed locally? And how fast the dual CPU computer is? If it is timing issue, both factors can influence it (slow network and fast computer).
BTW, statically linked app behaves the same way as before.April 29, 2005 at 8:23 am #5502
Unfortunatly I cannot install Munti edit locally – Licensing is for 25 network users
They are 3Ghz P4 processors.
The server does have its moments of being slow when loading.
If you can let me know how to install MEW locally then I will try this out.
p.s. What compiler / development enviroments do you have? I might be able to convert the test app to one of these to work on your machine.
I have made a final try with the test application by running it through the installshield dependancy checker and building an install of what it recommended. I have included the 3 files (vcl60.bpl, rtl60.bpl and syncor11.dll) that it believes are needed in the root – the MSI installer also has the microsoft c runtime and ole redistributables built in as well at the dll’s.
You can installl it wherever.April 29, 2005 at 8:25 am #5503April 29, 2005 at 8:26 am #5504
- You must be logged in to reply to this topic.