Deadlock-Problem with SB 7.3.3166

[NewsArchive]

Hi Friedrich,

as a quick information for you: I have a deadlock/hang with SB 7.3.3166
with no changes in my setup since SB 7.2.

This is just a quick note to you. I'll gather more information and keep
you posted.

Markus

[NewsArchive]

Hi Markus,

> as a quick information for you: I have a deadlock/hang with SB 7.3.3166
> with no changes in my setup since SB 7.2.
>
> This is just a quick note to you. I'll gather more information and keep
> you posted.

Is this in the IDE (during the compile) or in your install (at runtime)?

Thanks,
Friedrich

[NewsArchive]

Runtime.

I call a second SB-Installer from my first installer. The second runs
through the whole(?) script but does not terminate. The first installer
waits for the second and so the whole setup hangs.

Markus

[NewsArchive]

> Runtime.
>
> I call a second SB-Installer from my first installer. The second runs
> through the whole(?) script but does not terminate. The first installer
> waits for the second and so the whole setup hangs.

Hmm, nothing changed in #3166. There was a modification in #3162:

---
IMPROVEMENT: Installer: The "Progress Dialog" runs on its own thread to
avoid possible dead-locks when launching external applications
with the "Wait for Program" option enabled.
---

Can you reproduce this with a simple script?

Thanks,
Friedrich

[NewsArchive]

Hi Friedrich,

it is a sporadic problem. I'll force the usage of sbeventlog and then
I'll wait for the next time, the problem occurs.

One time, I've seen, that the first (outer) installer does not terminate
at the end.

So it is eventually not related to the call of the second (inner) setup.

Markus

[NewsArchive]

Hi Markus,

> it is a sporadic problem. I'll force the usage of sbeventlog and then I'll
> wait for the next time, the problem occurs.
>
> One time, I've seen, that the first (outer) installer does not terminate
> at the end.
>
> So it is eventually not related to the call of the second (inner) setup.

Very strange. Before we released SB73, we tested your "OuterSetup.sb7" and
"DBUpdater.sb7" scripts and the "wait" process worked as expected.

So perhaps it's another function that does not "return". Perhaps still the
"register font" function?

Friedrich

[NewsArchive]

Hi Friedrich,

I get not sbevent.log. What am I doing wrong? See attached screen shot.

Markus

[NewsArchive]

Markus,

>
> I get not sbevent.log. What am I doing wrong? See attached screen shot.
>

You cannot specify the path, only the file name!

test.exe /E2 "test.txt"

Friedrich

[NewsArchive]

:-(

Markus Zander

[NewsArchive]

>
> :-(
>

We can add a function to set both the path name and file name if you want.
We added the following in SB73:

---
FEATURE : Installer: Add new /E1 and /E2 event logging mode command line
options to create an unique sbevents_GUID.txt logging file
name (/E1) or set the name of the event logging file
(/E2 "filename").
---

Friedrich

[NewsArchive]

This would be great. So all logfiles would be in the same folder.

Markus

[NewsArchive]

>
> This would be great. So all logfiles would be in the same folder.
>

No problem! This will be available in the next build.

Friedrich

[NewsArchive]

Hi Friedrich,

here is the first result (see attached Screenshots).

Markus

[NewsArchive]

Hi Markus,

>
> here is the first result (see attached Screenshots).
>

So it happens after that last "Insert Line" Text File operation.

Can you reproduce this in a simple project or does it only happen in this
specific project?

Thanks,
Friedrich

[NewsArchive]

IMO, there is nothing in this function that can "lock" the system. Are you
using 0 in the Line parameter in this case?

What are you doing after this last function?

Friedrich

[NewsArchive]

Hi Friedrich,

I'll watching this. At this time, it seems to be related to the "close
progress dialog" function.

I'll keep you posted.

Markus

[NewsArchive]

Hi Markus,

> I'll watching this. At this time, it seems to be related to the "close
> progress dialog" function.
>
> I'll keep you posted.

Thank you! If possible, please also add a "Send Installer Event Entry"
after your line 2640.

Friedrich

[NewsArchive]

BTW: The send event... - help is out of date. See screen shot.

Markus

[NewsArchive]

>
> BTW: The send event... - help is out of date. See screen shot.
>

Fixed, thank you!

Friedrich

[NewsArchive]

Sorry, I missed the first screenshot with your source codes.

Can you add a "Send Installer Event Entry" directly after your lines 2635,
2636 and 2637? Perhaps this gives us more information.

Friedrich

[NewsArchive]

Hi Friedrich,

I can't get "Send Installer Event Entry" working. Perhaps this is
related to /E2 instead of /E or I am doing something wrong. Please have
a look at the attached screen shot.

Thanks.

Markus

[NewsArchive]

Hi Markus,

> I can't get "Send Installer Event Entry" working. Perhaps this is
> related to /E2 instead of /E or I am doing something wrong. Please have
> a look at the attached screen shot.

Please set the "Debug Mode" (General Information -> Generator Settings) to
'Minimum' and recompile.

Does this work?

Thanks,
Friedrich

[NewsArchive]

Yes, this works, but I don't understand the relation between debug mode
and send event entry.

Markus Zander

[NewsArchive]

> Yes, this works, but I don't understand the relation between debug mode
> and send event entry.

"Send Install Event Entry..." is a "debug" function. Quite a few developers
add their own "debug" information to the sbevents log. But they only need
(and want) this information in their Debug version, not in the Release one.

BTW, and some users do not want the sbevents log at all (and they disable it
with the $SB_DISABLEEVENTLOGFLAG$ Installer Flag; they only enable it in
their Debug mode installers).

Friedrich

[NewsArchive]

OK, and what is the difference between "minimum" and "full" debug mode?

Markus Zander

[NewsArchive]

>
> OK, and what is the difference between "minimum" and "full" debug mode?
>

You have to set Debug Mode to (at least) "Minimum" to enable the "Install
Event Entry" functionality. "Full" Debug Mode lets you run the installer in
the IDE Debugger (and it also enables the "Install Event Entry"
functionality).

Friedrich

[NewsArchive]

BTW, that's briefly shown in the "Learning SetupBuilder Part I" document

Jane

[NewsArchive]

Hi Friedrich,

my guess, that the problem is related to "close progress dialog" seems
to be true. Please have a look at the attached screen shots.

Thank you.

Markus

[NewsArchive]

Hi Markus,

> my guess, that the problem is related to "close progress dialog" seems
> to be true. Please have a look at the attached screen shots.

Very strange. The problem is that we can't reproduce it on any of our
machines :-( We tried at least 50 test projects yesterday on all kind of
operating systems. "Progress Dialog: Close" always worked as expected :-(

Can you reproduce this with a simple project?

Thanks,
Friedrich

[NewsArchive]

I'll try it.

BTW: The progress Dialog is already disappeared from the screen at this
time.

Markus

[NewsArchive]

Hi Friedrich,

the problem is sporadic. So it is nearly impossible, to test a stripped
down project. I've now tested with a simple project and there was no
problem. Perhaps you can add more logging information?

We have a planned release date at thursday. Should I go back to SB7.2 or
do you think we could fix this until then?

Thanks.

Markus

[NewsArchive]

Hi Markus,

> the problem is sporadic. So it is nearly impossible, to test a stripped
> down project. I've now tested with a simple project and there was no
> problem. Perhaps you can add more logging information?
>
> We have a planned release date at thursday. Should I go back to SB7.2 or
> do you think we could fix this until then?

I believe that the following change has something to do with it (added in
September 2010 and released in the #3097 pre-release on October 01, 2010):

---
IMPROVEMENT: Installer: The "Progress Dialog" runs on its own thread to
avoid possible dead-locks when launching external applications
with the "Wait for Program" option enabled.
---

We'll review the code again. The main problem is that we can't replicate it
here and we did not receive any similar report :-( So we can only guess
what causes it.

I would suggest to go back to 7.2 because the same code (unchanged!) is in
all releases after build #3062.

Friedrich

[NewsArchive]

We tested 80 different scenarios on completely different machines and
operation systems during the last 5 hours, but we never ran into this
"dead-lock" problem :-( Continue testing...

Friedrich

[NewsArchive]

Hi Friedrich,

is it possible to debug the setup, so I can send you a stack trace or
something else meaningful?

We have only one machine, on which the problem occurs nearly one time a
day. On all other machines it occurs rarely or never.

Markus

[NewsArchive]

I have send you a mail with a link to the setup, which hangs sometimes.
Perhaps this helps you to reproduce this.

FYI: On at least one of our machines, it occurs only once after a fresh
reboot...

Markus

[NewsArchive]

Hi Markus,

> is it possible to debug the setup, so I can send you a stack trace or
> something else meaningful?
>
> We have only one machine, on which the problem occurs nearly one time a
> day. On all other machines it occurs rarely or never.

I think we know where it "dead-locks" (in theory), but not why it happens on
your machine. We have added two new debug events and have slightly modified
the runtime. If you are interested, we can upload a development build
tomorrow.

Friedrich

[NewsArchive]

Hi Markus,

> the problem is sporadic. So it is nearly impossible, to test a stripped
> down project.

We have slightly modified the runtime. If you are interested, we can upload
a development build tomorrow to see if this makes a difference to you.

Friedrich

[NewsArchive]

Hi Friedrich,

please, can we wait until we have released our next version? After that
I would be very happy to test your new development build.

Markus

[NewsArchive]

Hi Markus,

> please, can we wait until we have released our next version? After that I
> would be very happy to test your new development build.

Absolutely no problem.

Friedrich

[NewsArchive]

Hi Friedrich,

FYI: I'm now back on SB 7.2.3015 and everything is OK.

Markus

[NewsArchive]

Markus,

>
> FYI: I'm now back on SB 7.2.3015 and everything is OK.
>

Yes, I am sure it's caused by the change in the #3097 pre-release (October
01, 2010).

But I think that the runtime change we made yesterday will fix this. We
can't test it because we do not see the deadlock problem here, but in
theory, it "should" fix it.

Friedrich

[NewsArchive]

> Markus,
>
>> [3 quoted lines suppressed]
>
> Yes, I am sure it's caused by the change in the #3097 pre-release (October
> 01, 2010).
>
> But I think that the runtime change we made yesterday will fix this. We
> can't test it because we do not see the deadlock problem here, but in
> theory, it "should" fix it.
>
> Friedrich

Friedrich,

I tested my original problem with the multi-threading UI that I believe was
the cause of this fix.
Everything is still working here for me with 3166.

Rick

[NewsArchive]

Hi Rick,

> I tested my original problem with the multi-threading UI that I believe
> was the cause of this fix.
> Everything is still working here for me with 3166.

Thank you for the information!

We made a minor runtime modification (in our internal source codes for the
next build). It's possible that a combination of the SendMessage() and
WaitForSingleObject() Windows APIs can cause, under certain circumstances,
such a deadlock problem. We tested more than 300 projects (with the #3166
runtime) but it was impossible for us to replicate this deadlock issue. So
this code change is only a "theoretical fix" and I hope it will work for
Markus.

Thanks again.

Friedrich

[NewsArchive]

Hi Friedrich,

we have released our next version and can now check you runtime
modification. Please, could you send me your acutal development version?

Thanks.

Markus

[NewsArchive]

Hi Markus,

> we have released our next version and can now check you runtime
> modification. Please, could you send me your acutal development version?

Download link for the internal build #3177 sent.

Thanks,
Friedrich